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Related Applications 
[0001] This application is a regular filed appUcation of and claims, for the purposes 
of priority, the benefit of U.S. Provisional Application Serial No. 60/567,980, entitled 
"Graphical User Interface for Representing, Monitoring, and Interacting with Process 
Control Systems," which was filed on May 4, 2004 and which this application hereby 
expressly incorporates by reference herein in its entirety. This appUcation is also 
related to U.S. Patent Application Serial Number 10/625,481, entitled "Integration of 
Gr^hic Display Elements, Process Modules and Control Modules in Process Plants." 
which was filed on July 21 , 2003, and which pubUshed as U.S. Publication No. 
2004/0153804 on August 5, 2004, which, in turn, is a Continuafion-in-Pait of U.S. 
Patent Application Serial No. 10/278,469, entitled "Smart Process Module and 
Objects in Process Plants," which was filed on October 22, 2002, and which published 
as U.S. Publication No. 2004/0075689 on April 22, 2004, the entire disclosures of 
which are hereby expressly incorporated by reference herein in their entirety. This 
^Ucation is also related to U.S. Patent AppUcation Serial Number 10/368,151 
entitled "Module Class Objects in a Process Plant Configuration System," which was 
filed on February 18, 2003, and which pubUshed as U.S. Publication No. 
2004/0199925 on October 7, 2004, the entire disclosure of which is hereby expressly 
incorporated by reference herein in its entirety. This appUcation is also related to the 
following patent appUcations, which are being filed as International (PCT) 
appUcations on the same date as this application and which this appUcation hereby 
expressly incorporates by reference herem in their entirety. "Associated Graphic 
Displays in a Process Environment" (Atty. Docket No. 06005/41 1 1 1); "User 
Configurable Alarms and Alarm Trending for Process Control Systems" (Atty. 
Docket No. 06005/41 1 12); "Integration of Process Modules and Expert Systems in 
Process Plants" (Atty. Docket No. 06005/41 1 13); "A Process Plant User Interface 
System Having Customized Process Graphic Display Layers in an Integrated 
Environment" (06005/41114); "Graphics Integration into a Process Configuration and 
Control Environment" (Atty. Docket No. 06005/41 1 16); "Graphic Element with 
Multiple Visualizations in a Process Environment" (Atty. Docket No. 06005/41 117); 
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"Syston for Configuring Graphic Display Elements and Process Modules in Process 
Plants (Atty. Docket No. 06005/41 118); "Graphic Display Configuration Framework 
for Unified Process Control System Interface" (Atty. Docket No. 06005/41124); 
"Markup Language-Based, Dynamic Process Graphics in a Process Plant User 
Interface" (Atty. Docket No. 06005/41127); "Methods and Apparatus for Modifying 
Process Control Data" (Atty. Docket Nos. 06005/591622 and 20040/59-11622); 
•Methods and Apparatus for Accessing Process Control Data" (Atty. Docket Nos. 
06005/591623 and 20040/59-11 623); "Integrated Gr^hical Runtime Interface for 
Process Control Systems" (Atty. Docket Nos. 06005/591628 and 20040/59-11628); 
"Service-Oriented Architecture for Process Control Systems" (Atty. Docket Nos, 
06005/591629 and 20040/59-1 1629). 

Technical Field 

[0002] The present invention relates generally to process plants and, more 
particularly, to the integration and use of a graphic display editor and graphic display 
objects at a system level of a process control and simulation system to enable the 
creation and use of common graphic display elements in various activities associated 
with plant configuration, control, maintenance, and simidation. 

Description of the Related Art 

[0003] Distributed process control systems, like those used in chemical, petroleum 
or other processes, typically include one or more process controllers communicatively 
coupled to one or more field devices via analog, digital or combined analog and 
digital buses. The field devices, which may be, for example, valves, valve 
positioners, switches and transmitters (e.g., temperature, pressure, level and flow rate 
sensors), are located within the process environment and perform process functions 
such as opening or closing valves, measuring process parameters, etc. Smart field 
devices, such as the field devices conforming to the well-known Fieldbus protocols, 
like the FOUNDATION™ Fieldbus protocol, may also perform control calculations, 
alarming functions, and other control functions commonly implemented within the 
controller. The process controllers, which are also typically located within the plant 
environment, receive signals indicative of process measurements made by the field 
devices and/or other infonnation pertaining to the field devices and execute a 
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controller application tiiat runs, for example, different control modules which make 
process control decisions, generate control signals based on the received information 
and coordinate with the control modules or blocks being executed in the field devices, 
such as HART and Fieldbus field devices. The control modules in the controller s^d 
the control signals over the communication lines to the field devices to thereby 
control the operation of the process. 

[0004] Information from the field devices and the controller is usually made 
available over a data highway to one or more other hardware devices, such as operator 
workstations, personal computers, data historians, report generators, centralized 
databases, etc., typically placed in control rooms or other locations away firom the 
harsher plant environment. These hardware devices run applications that may, for 
example, enable an operator to perform fimctions with respect to the proeess,-such as 
changing settings of the process control routine, modifying the operation of the 
control modules within the controller or the field devices, viewing the current state of 
the process, viewing alarms generated by field devices and controllers, simulating the 
operation of the process for the purpose of training personnel or testing the process 
control software, keeping and updating a configuration database, etc. 

[0005] As an example, the DeltaVTM control system, sold by Emerson Process 
Management includes multiple applications stored within and executed by different 
devices located at diverse places within a process plant. A configuration application, 
which resides in one or more operator workstations, enables users to create or change 
process control modules and download these process control modules via a data 
highway to dedicated distributed controllers. Typically, these control modules are 
made up of communicatively interconnected function blocks, which are objects in an 
object oriented programming protocol that perform functions within the control 
scheme based on inputs thereto and provide outputs to other function blocks within 
the control scheme. The configuration application may also allow a designer to create 
or change operator interfaces which are used by a viewing application to display data 
to an operator and to enable the operator to change settings, such as -set points, within 
the process control routine. Each dedicated controller and, in some cases, field 
devices, stores and executes a controller application that runs the control modules 
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assigned and downloaded thereto to implement actual process control functionality. 
The viewing applications, which may be nm on one or more operator workstations, 
receive data from the controller application via the data highway and display this data 
to process control system designers, operators, or users using the user interfaces, and 
may provide any of a number of different views, such as an operator's view, an 
engineer's view, a technician's view, etc. A data historian application is typically 
stored in and executed by a data historian device that collects and stores some or all of 
the data provided across the data highway while a configuration database application 
may run in a still further computer attached to the data highway to store the current 
process control routine configuration and data associated therewith. Alternatively, the 
configuration database may be located in the same workstation as the configuration 
application. 

[0006] As the number and type of control and support applications used in a 
process control environment have increased, different graphical display applications 
have been provided to enable users to effectively configure and use these applications. 
For exanq^le, graphical display applications have been used to support control 
configuration applications to enable a configuration engineer to graphically create 
control programs to be downloaded to the control devices within a process plant. 
Additionally, graphical display ^plications have been used to enable control 
operators to view the current functioning of the process plant, or areas of the process 
plant, to enable maintenance personnel to view the state of hardware devices within 
the process plant, to enable simulation of the process plant, etc. However, these 
graphical display applications have, in the past, been created as part of or to support 
the specific ^plications with which they are associated, and thus are generally limited 
in usefulness to the specific process function for which they were created. For 
example, it is difficult, if not impossible, to use a graphical program created to 
support a control or other operator in a maintenance, a configuration or a simidation 
fimction. 

[0007] As a particular example, some process control configuration applications 
presently include a library of template objects, such as fimction block template objects 
and, in some cases, control module template objects, which are used to create a 
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control strategy for a process plant. The template objects have default properties, 
settings and methods associated therewith and ttie engineer using a graphical 
configuration application can select these template objects and ^entially place 
copies of the selected template objects into a CMifiguxation screen to develop a control 
module. During the process of selecting and placing the template objects into tiie 
configuration screen, the engineer interconnects the inputs and outputs of tiiese 
objects and changes their parameters, names, tags and other properties to create a 
specific control module for a specific use in the process plant. After creating one or 
more such control modules, the engineer can tiien instantiate the control module and 
download it to the appropriate controlter or controllers and field devices for execution 
during operation of the process plant. 

[0008] Thereafter, the engineer may use a different graphical display creation 
application to create one or more displays for operators, maintenance persoimel, etc. 
witliin the process plant by selecting and building display objects in tiie display 
creation jqpplication. These displays are typically implemented on a system wide 
basis in one or more of the workstations and provide preconfigured displays to the 
operator or maintenance persons regarding the operating state of tiie control system or 
the devices within the plant. These di^lays generally t^e the form of alarming 
displays that receive and display alanns generated by controllers or devices within the 
process plant, control displays indicating the operating state of the confaollers and 
other devices within the process plant, maintenance displays indicating the 
fimctioning state of flie devices within the process plant, etc. However, these displays 
are generally preconfigured to display, in known maimers, information or data 
received from the process control modules or the devices within the process plant. In 
some systems, displays are created by a graphic depiction that represents a physical or 
a logical element and that is communicatively tied to the physical or logical element 
to receive data about the physical or logical element. The graphic on the display 
screen may change in response to certain events, such as received data to illustrate, for 
example, that a tank is half fiiU, to illustrate the flow measured by a flow sensor, etc. 
However, the graphical displays used for configuration, operator control, maintenance 
and simulation activities are generally created separately fi-om one another using 
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different graphical editors. Still further, the limited graphical capabilities of these 
displays are hard to implement and are not done so as part of any graphical object. 

[0009] Thus, similar to the control configuration application, the display creation 
application may have template graphical display items, such as tanks, valves, sensors, 
operator control buttons like slide bars, on/off switches, etc. which may be placed on 
a screen in any desired configuration to create an operator display, maintenance 
display and the like. When placed onto the screen, individual graphic items may be 
interconnected on the screen in a manner tiiat provides some information or display of 
the iimer-workings of the process plant to users. However, to animate the graphic 
display, the display creator must manually tie each of flie graphical items to data 
generated within the process plant, such as data measured by sensors or indicative of 
valve positions, etc. by specifying a conmaunication link between the graphic item and 
the relevant data source within the process plant. This process is tedious, time 
consuming and may be fraught with error. 

[0010] While the control template objects within the control configuration 
application and the display items within ihe display creation application are 
convenient because they can be copied and used to create many different control 
modules and gr^hical displays, there is often a need to create numerous of the s;ame 
control module and graphical display for different equipment within the process plant. 
For example, many medium to large sized process plants have numerous instances of 
the same or similar equipment that can be controlled and viewed using the same basic 
general control module and display. To create these numerous control modules and 
displays, however, a general control module or display module is created and this 
general control or display module is then copied for each of the different pieces of 
equipment for which it is applicable. Of course, after being copied, each of the new 
control or display modules must be manually altered in the configuration application 
to specify the particular equipment to which it is attached and all of these control and 
display modules must then be instantiated and downloaded to the process control 
system. 

[0011] Unfortunately, the control modules and displays items discussed above are 
not modular in any manner. Thus, after being copied, each of the control modules and 



-6- 



wo 2005/109130 



PCT/US2005/015942 



displays must be manually and individually altered using the appropriate 
configuration application to specify the equipment within the plant to which they are 
to be associated, hi a plant having many copies of the same type of equipment <i.e., 
replicated equipment), this process is tedious, time consuming and fraught with 
operator introduced errors. Still further, once programmed, these different control 
modules and displays are not aware of each other. Therefore, to make a change to the 
control modules once created, the engineer or operator must manually make the same 
change to each of the different control modules for the different replicated equipment 
which, again, is time consuming and tedious. The same problem applies for the 
graphical views created for the different sets of replicated equipment within the plant, 
hi other words, once a specific control module or a specific graphical view is created 
(individually or by being copied firom a template object) and is then tied to a 
particular set of equipment withm the plant, this control module or graphical view 
exists as a separate entity or object within the system without any automatic 
awareness of the other control modules or graphical displays that are the same or 
similar to it. As a result, changes applicable to every one of the control modules and 
graphical displays of a particular type must be made individually on those modules 
and displays. This problem is even more evident when graphical views are created 
for the same equipment but in different functional contexts withm the plant, such as 
for control viewing, mamtenance viewing and simulation functions, hi this case, the 
graphical views are created separately without any knowledge or awareness of one 
anoth^. 

[00121 Thus, while graphic displays have been provided in and associated with 
different applications used for different general activities performed withm a process 
plant, these graphic displays and associated graphic display editors were generally 
added on at the functional level of the appUcation for which they were -ra-eated to 
support. As a result, the graphical editors, to the extent they existed, have only 
enabled the user to create graphics that support specific functionality needed by a 
specific application. Previous process plants did not provide a grapliical display 
editor that could be used by or that could support the graphical needs of various or 
multiple activities being performed in the context of plant configuration and support. 
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Thus, for example, a graphical display editor used to support or enable control 
configuration activities only enabled the user to create control progranas and did not 
support the needs or fimctionaUty of operator or maintenance displays. Similarly, 
graphic display editors used for creating operator views, maintenance views, etc. to be 
provided to a control operator or maintenance technician during operation of a plant, 
did not support functionality associated with configuration activities, simulation 
activities, etc. As a result of the graphic display needs being supported at the 
individual functional levels of the process plant, such as at the control configuration, 
maintenance support, control operator support and simulation support fimctional 
levels, different ones of the displays created by these various editors &id up modeling 
and depicting ttie same components wittiin the plant, which results in the duplication 
of graphical display efforts by various different personnel with the process plant This 
dupUcation of effort is manifested not only in the effort needed to create the different 
graphical displays depicting the same process element for different uses, but also in 
the effort needed to tie the graphic elemaits used in different display ^plications to 
the actual hardware or software elements within the process plant to which they are 
associated. 

[0013] Because graphical support for various process plant activities has been 
provided after the fact, and as part of the actual activity being performed, graphical 
support is not integrated in the plant environment in a manner that enables common 
graphics to be created and used within the plant at the various different functional 
levels of the plant. This non-integration of graphics leads to the gr^hics actually 
created for the different functions being different fi-om function to function or from 
application to application, which can lead to confusion on the part of users who, while 
familiar with one specific type of graphical display, might occasionally need to view 
different displays associated with different operations or functions within the plant. 
Likewise, as noted above, the provision of graphical display support at the various 
different functional levels of the plant leads to the duplication of graphic support, both 
in creating displays and properly connecting the elements within the displays to actual 
hardware or software elements within the plant. 
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[00141 Additionally, error detection and other programming is useful for detecting 
conditions, errors, alarms, etc. associated with control loops ruiming on the different 
controllers and problems wiliiin the individual devices. Such error detection has 
traditionally been performed at the different functional levels of the process plant and 
has been displayed on graphic displays created for those different functional activities. 
It has been difficult, therefore, to program the process control system to recognize 
system-level conditions or errors that must be detected by analyzing data from 
different, possible diversely located devices within the process plant and even more 
difficult to show these types of errors on operator displays that have not been created 
to indicate or present such system-level condition information to operators or 
maintenance persoimeL Also, it is difficult to animate objects within operator 
displays with these altemate sovurces of information or data for the different elements 
within the display. 

Summary of Disclosure 

[0015] Graphic elements and graphic displays are provided for use in a process 
enviroimient to display information to one or more users about the process 
enviroimient, such as the current state of devices within a process plant The graphic 
elements and displays include one or more objects, each of which includes a 
visualization, which depicts an entity within the process environment, a property 
associated with the depicted process entity and a routine that operates in conjunction 
with the visualization and the property to cause a change in the visuaUzation based on 
a change in the property, or to cause a change in the process envirormient based on 
user input tlirough the visualization. In this manner; the graphic objects can be used 
to create displays that graphically illustrate, through animations and other visual 
operations, the changing state of the process or detected events within the process. 
These same graphic elements may be used to enable users to interact with a 
visualization on a user interface screen, such as thr ough a mouse or a keyboard 
device, to cause a change in the object property, which may then provide an input to a 
device within the process plant. 
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Brief Description of the Drawings 

[0016] Fig. 1 is a block diagram of a distributed process control network located 
within a process plant including operator workstations that implement display routines 
and other applications associated with various functions within the process plant, as 
well as a workstation that provides system level graphical support that may be used to 
create graphic display elements and graphic displays for each of the various functional 
areas of the plant; 

[0017] Fig. 2 is a logical block diagram illustrating the integration of system level 
graphical support within a process plant control, viewing and simulation system; 

[0018] Fig. 3 is a logical diagram illustrating a configuration environment in which 
graphic elements and displays are created and a runtime environment in which 
gr^hic elements and displays may be executed; 

[0019] Fig. 4 is a simplified display screen produced by a graphical editor to enable 
a user to create or edit a graphic element in the form of a pump element; 

[0020] Fig. 5 is a further display screen produced by a graphical editor while 
producing a graphic element in the form of a reactor; 

[0021] Fig. 6 is a block diagram illustrating one manner in which various 
visualizations may be tied to or associated with a graphic element; 

[0022] Fig. 7 depicts a section of a screen display showing a first property view 
associated with a graphic element; 

[0023] Fig. 8 depicts a section of a screen display showing a second property view 
associated with a graphic element; 

[0024] Fig. 9 depicts an actions/animations section of a display screen showing 
actions associated with properties of a graphic element; 

[0025] Fig. 10 is a block diagram illustrating a manner in which visual triggers may 
be integrated with properties and visualizations of a graphic element; 

[0026] Fig. 1 1 depicts a dialog box that may be use to provide or define a transform 
animation for a visualization of a graphic element; 
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[0027] Fig. 12 depicts a dialog box that may be use to provide or define a propCTty 
animation , including a color animation, for a visualization of a graphic element; 

[0028] Fig. 13 is a diagram generally illustrating the manner in which ^aphic 
elements may be tied to a runtime environment through a r^olution table; 

[0029] Fig- 14 is a block diagram depicting a display element bound to multiple 
different data sources in a process environment; 

[0030] Fig. 15 is a display screen produced by a graphical editor while producing a 
graphic display from multiple display elements and coimectors; 

[0031] Fig. 16 is a display screen for creating a graphic display illustrating various 
visualizations associated with a graphic element placed within the graphic display; 

[0032] Fig. 17 is a display screen associated with a graphic di^lay made up of 
various interconnected graphic elements and connectors; 

[0033] Fig. 1 8 is a set of graphic display screens that may be accessed via the 
graphic display of Fig. 17 to show a control panel and a faceplate for an element 
within the display of Fig. 17; . 

[0034] Fig. 1 9 is a display screen of a graphic display illustrating a lime kiln made 
up of various display elements, and providing data from various other applications 
and data sources Avithin a process plant; 

[0035] Figs. 20A-20E are graphic display screens illustrating different views of a 
lime kihi having the same look and feel, including an opearator view, an engineering 
view, a business view, a simulation view and a maintenance view; 
[0036] Figs. 21 A and 21B are display screens associated with a control routine 
used to run the lime kibi shown in Figs. 20A-20E; 

[0037] Fig. 22 is block diagram illustrating associations between various different 
graphic displays at various levels, including physical levels and functional levels; 

[0038] Fig. 23 depicts a first configuration screen illustrating a graphical 
configuration laierarchy associated with a configuration system; 
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[0039] Fig. 24 depicts a second configuration screen illustrating a graphical 
configuration hierarchy showing one manner in which graphic elements and graphic 
displays may be assigned to and integrated with other elements within the 
configuration system; and 

[0040] Fig. 25 depicts a dialog box that may be provided to a user to summarize the 
manner in which one or more graphic displays are assigned within a process plant 
configuration system. 

Detailed Description 

[0041] Fig. 1 illustrates an example process plant 10 in which system level 
graphical support is provided to various functional areas of the plant 10, As is typical, 
the process plant 10 includes a distributed process control system having one or more 
controllers 12, each connected to one or more field devices 14 and 16 via iiq)Ut/ou1put . 
(I/O) devices or cards 18 which may be, for example, Fieldbus interfaces, Profibus 
interfaces, HART interfaces, standard 4-20 ma interfaces, etc. The controllers 12 are 
also coupled to one or more host or operator workstations 20-23 via a data highway 
24 which may be, for example, an Ethernet link. A database 28 may be connected to 
the data highway 24 and operates as a data historian to collect and store parameter, 
status and other data associated with the controllers and field devices within the plant 
10 and/or as a configuration database that stores the current configuration of the 
process control system within the plant 10 as downloaded to and stored within the 
controllers 12 and field devices 14 and 16. The database 28 may additionally store 
graphical objects created in the manner described herein to provide graphical support 
within the process plant 10. While the controllers 12, I/O cards 18 and field devices 
14 and 16 are typically located down within and distributed throughout the sonaetimes 
harsh plant environment, the operator workstations 20-23 and the database 28 are 
usually located in control rooms or other less harsh environments easily assessable by 
controller or maintenance personnel. However, in some cases, handheld devices may 
be used to implement these fimctions and these handheld devices are typically carried 
to various places in the plant. 

[0042] As is Icnown, each of the controllers 12, which may be by way of example, 
the DeltaV™ controller sold by Emerson Process Management, stores and executes a 
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controller application that implements a control strategy using any number of 
different, independently executed, control modules or blocks 29. Each of the control 
modules 29 can be made up of what are commonly referred to as function blodcs 
wherein each function block is a part or a subroutine of an overall control routine and 
operates in conjunction with other function blocks (via communications called links) 
to implement process control loops within the process plant 10. As is well known, 
function blocks, which may be objects in an object oriented programming protocol, 
typically perform one of an input fimction, such as that associated with a transmitter, a 
sensor or other process parameter measurement device, a control function, such as 
that associated with a control routine that performs PID, fuzzy logic, etc. control, or 
an ou^ut function that controls the operation of some device, such as a valve, to 
perform some physical function within the process plant 10. Of course hybrid and 
other types of complex function blocks exist such as model predictive controllers 
(MFCs), optimizers, etc. While the Fieldbus protocol and the DeltaV system protocol 
use control modules and function blocks designed and implemented in an object 
oriented programming protocol, the control modules could be designed using any 
desired control programming scheme including, for example, sequential function 
block, ladder logic, etc. and are not limited to being designed and implemented using 
the function block or any othCT particular programming technique. 

[0043] In the plant 1 0 illustrated in Fig. 1 , the field devices 14 and 16 connected to 
the controllers 12 may be standard 4-20 ma devices, may be smart field devices, such 
as HART, Profibus, or FOUNDATION™ Fieldbus field devices, which include a 
processor and a memory, or may be any other desired type of devices. Some of these 
devices, such as Fieldbus field devices {labeled witti reference number 16 in Fig. 1), 
may store and execute modules, or sub-modules, such as function blocks, associated 
with the control strategy implemented in the controllers 12. Function blocks 30, 
which are illustrated in Fig. 1 as being disposed in two different ones of the Fieldbus 
field devices 16, may be executed in conjunction with the execution of the control 
modules 29 within the controllers 12 to implement process control, as is well known. 
Of course, the field devices 14 and 16 may be any types of devices, such as sensors, 
valves, transmitters, positioners, etc. and the I/O devices 18 may be any types of I/O 
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devices conforming to any desired communication or controller protocol such as 
HART, Fieldbus, Profibus, etc, 

[0044] In the process plant 10 of Fig. 1, the workstations 20-23 may include 
various apphcations that are used for various different functions performed by the 
same or different personnel within the plant 10. Each of the workstations 20-23 
includes a memory 31 that stores various applications, progranas, data structures, etc. 
and a processor 32 which may be used to execute any of the explications stored in the 
memory 31. In the example illustrated in Fig. 1 , the workstation 20 is designated as a 
configuration workstation and includes one or more configuration explications 33 
which may include, for example, control module creation applications, operator 
interface applications and other data structures which can be accessed by any 
authorized configuration engineer to create and doAvnload control routines or 
modules, such as the control modules 29 and 30, to the various controllers 12 and 
devices 16 of the plant 10. The workstation 21 is generally illustrated in Fig. 1 as a 
control operator viewing workstation and includes a number of display applications 
34 which may provide a control operator witii various displays during operation of the 
process plant 10 to enable the operator to view and control what is happening within 
the process plant 10 or in various sections of the plant. The applications 34 may- 
include support applications 34a such as control diagnostic apphcations, tuning 
apphcations, report generation apphcations or any other control support apphcations 
that may be used to assist a control operator in performing control Amotions. 
Similarly, the workstation 22 is illustrated as a maintenance viewing workstation and 
includes a number of maintenance applications 35 that may be used by various 
maintenance personnel to view the maintenance needs of the plant 10, to view the 
operating or working condition of various devices 12, 14, 16, etc. Of course, the 
applications 35 may include support applications 35a such as maintenance diagnostic 
apphcations, caUbration apphcations, vibration analysis applications, report 
generation applications or any other maintenance support applications that may be 
used to assist a maintenance person in performing maintenance functions within the 
plant 10. Additionally, the workstation 23 is indicated as a simulation workstation 
which includes a number of simulation applications 36 that may be used to simulate 
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operation of tiie plant 10 or various sections of the plant 10 for any number of 
purposes, including for training purposes, for plant modeling purposes to assist in 
plant maintenance and control, etc. As is typical, each of the workstations 20-23 
includes a display screen 37 along with other standard peripheral devices, like a 
keyboard, a mouse, etc. 

[0045] Of course, while the various configuration, contirol, maintenance and 
simulation applications 33-36 are illushated in Fig. 1 as being located in different 
workstations dedicated to one of those functions, it will be understood that the various 
appUcations 33-36 associated with these or other plant functions may be located in 
and executed in the same or different workstations or computers within the plant 10, 
depending on the needs and set up of the plant 10. Thus, for example, one or more 
simulation appUcations 36 and control applications 33 may be executed in the same 
workstation 20-23, while different individual simulation applications 36 or different 
individual control applications 33 may be executed in dififer^t ones of the 
workstations 20-23. 

[0046] In the past, the development of the different applications used in the 
differrait functional areas of the plant 10 was performed fairly independently. Thus, 
the development of the configuration applications 33 was not integrated wifli the 
simulation applications 36, the maintenance applications 35 or the operator control 
applications 34. In fact, in many instances, a plant may have included appUcations for 
the different functional areas that were developed by different companies or software 
suppHers, and which were in fact developed to run independently of Hie oth«r 
software within the plant 10. As a result of this independent development and 
operation of the different appUcations associated with the various functional areas of 
the plant 10, plant personnel were generally required to configure or set up a plant 
separately at each of the configuration, operator control, maintenance and simulation 
functional levels. In particular, the same or different plant personnel generally had to 
use different programs to estabUsh new data structures and graphic displays at each of 
the fiinctional levels. Thus, with respect to Fig. 1, each of the various applications 33- 
36 the perfomied configuration, control, maintenance and simulation functions 
generaUy included or used different graphic display editors and database structiures to 
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assist the plant personnel in perfonning these configuration, operator control, 
maintenance and simulation functions. In many instances, these different graphic 
display editors and databases were used to create different graphic displays to depict 
or model the same sections or areas of the plant 10 or the same hardware within the 
plant 10, and to assist different plant personnel to visualize and understand what is 
happening within the process plant in the context of configuration, operator control, 
maintenance or simulation activities. 

[0047] Because the appUcations 33-36 and the associated displays for each of the 
various functions within the plant 10 were generally developed and implemented 
independently of one another, sometimes by different people and even different 
companies, the graphic displays created or used in the different functional areas of the 
process plant were not integrated in any consistent or eaisily imderstood maimer firom 
the standpoint of providing graphical visuaUzation. As a result, the independent 
creation and execution of graphic displays at the various different functional levels of 
the plant led to the graphic displays looking different fi-om function to fimction, so 
that there was not consistent look and feel to the graphic displays across the functional 
areas. Additionally, this independent creation led to the duplication of effort in 
creating graphic displays for the same sections or areas of the plant but for different 
functional uses, and required that the graphic displays so created be tied into and 
receive data from the various devices within plant 10, such as the controllers 12 and 
the field devices 14, 16, separately at the functional levels of the plant 10. This fact, 
in turn, required the duplication of database structures to track the same hardware 
elements for the different displays. Thus, for example, in the past, a first application 
(e.g., one of the applications 35) was used to create a maintenance display that 
illustrates a section of the plant 10 for maintenance purposes while a second 
application (e.g., one of the applications 34) was used to create a control operator 
display that illustrates the same section of the plant 10 for control piirposes. The 
displays created separately by these different display editors could be quite different 
in look and feel, making it difficult for a user to switch back and forth between the 
maintenance display and the operator display without becoming easily confused or 
without requiring training on each type of display. Likewise, effort was duplicated in 
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creating both displays independently in the different appUcations 34 and 35. and 
additional efTort was expanded to create database structures to separately tie or 
connect the maintenance display and the control operator display to the same 
hardware elements withm the plant 10 to receive sometimes the same or similar data 
from those hardware elements. 

[0048] To alleviate these inefficiencies and to provide for more widely usable and 
understandable graphics within the plant 10, a graphical support layer is provided at a 
system level of the process plant 10 to support the gr^hic display and data stracture 
needs of each of the various functional areas of the plant 10, including the 
configuration, operator viewing, maintenance viewing, simulation and other 
functional areas of the plant 10. This system level of support is depicted 
diagrammatically m Fig. 2, which illustrates a plant operational level 40, a plant 
functional level 42 and a system level 44. As will be understood firom Fig. 2, the 
plant operational level 40 includes the controllers 12, field devices 14, 16, etc. which 
execute the control routines or modules 29 and 30, as well as other software run 
within the plant 10 to implement plant operations during runtime of the plant. The 
plant functional level 42 is depicted as including a configuration function block 46, a 
control fimction block 47, a maintenance fimction block 48 and a simulation block 49, 
although other or different fimctions, such as an engineering and a business function, 
could be provided as well. The configuration function block 46 implements the 
configuration routines 33 which interface or communicate with components within 
the plant operational level 40 to provide control strategies or control modules thereto. 
The control function block 47 includes the control viewing and other applications 34 
and 34a which also interface or communicate typically directly with the various 
physical and logical components within the plant operational level 40 to implement 
operator initiated changes within the plant 10, to provide information to the operator 
via control displays 34, to acquire data for the control applications 34a, etc. The 
maintenance function block 48 includes the maintenance routines and applications 35 
and 35a which interface or communicate with various physical and logical 
components within the plant operational level 40 to implement maintenance 
procedures, to collect maintenance data, to provide maintenance data or information 
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to a maintenance person via maintenance displays 35, to run diagnostic applications 
35a, etc. Likewise, the simulation function block 49 includes simulation routines 36 
which implement simulations of the plant 10 and which may be conamunicatively 
coupled to components within the plant operational level 40 to obtain data regarding 
the plant 10. 

[0049] As illustrated in Fig. 2, the system level support layer 44 ties into and 
supports each of the function blocks 46-49 within ttie plant functional layer 42 to 
enable, for example, the creation and maintaining of common database and display 
structures, such as software objects, graphic elements and graphic displays for use in 
the various functional areas 46-49. More particularly, the system level support layer 
44 includes appUcation, database and graphical support elements that enable the 
graphical activities performed in each of the function blocks 46-49 to be integrated 
together, or to be developed using common database stmctures and graphic elements 
created at the system support layer 44. To provide this system level support, the 
system support layer 44 may include a graphical editor 50 and a graphical object 
database 52. The graphical editor 50 may be used to create graphic elements 54 and 
grsqphic displays 56, while the graphic object database 52 stores the elements 54 and 
displays 56 in a memory accessible by the editor 52 and by the various applications in 
the blocks 46-49. The database 52 may also store oth^ objects 58 and data structures 
that connect the graphic elements 54 to individual hardware and software elements 
within the plant operational level 40. Additionally, the database 52 may store graphic 
element or display templates or primitives that may be used to create further graphic 
elements or displays. As will be imderstood from Fig. 2, the graphic display elements 
54, displays 56 and other database structures 58 may be used by in any and all of the 
functional blocks 46-49 to create and use graphics associated with those functional 
blocks. 

[0050] Generally speaking, the system level support block 44 provides a maimer of 
integrating the graphics used in the process plant 10 of Fig. 1 in all of the functional 
areas 46-49, to thereby reduce or eliminate the necessity of repeatedly creating 
different grapliic elements for the same plant equipment in different functional 
contexts, and to make it easy for a user in each of the functional areas 46-49 to tie into 
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data associated with the equipment being displayed in graphical views associated with 
those functional areas. As will be understood, the system level support layer 44 may 
be used to provide graphics and database support for multiple ^pUcations ineach of 
the functional areas 46-49, for different applications in different ones of the fimctional 
areas 46-49, etc, 

[0051] Referring again to Fig. 1, the system level support block 44 may be 
implOTiented using an additional workstation or user interface 60 which may be 
comiected to each of the other workstations 20-23. The workstation 60 may generally 
store the graphics editor 50 and database 52 and may store the other elements 54, 56 
and 58 if so desired. Additionally, the workstation 60 maybe communicatively 
comiected to the workstations 20-23 via the databus 24, via separate wired or wireless 
communication connections (illustrated by dotted lines in Fig. 1) or in any other 
desired manner. In tiie configuration illustrated in Fig. 1, the workstation 60 stores 
and executes the display editor 50 to enable a user to create graphic elements and to 
group such elements into one or more graphic displays, both of which are referred to 
herein as display modules. These display modules may be then stored in the database 
52 to be accessed and used by various ones of the functional blocks 46-49 illustrated 
in Fig. 2 and implemented on the various workstations 20-23. While, for the s^e of 
illustration, the functionality of the system level block 44 and the function level 
blocks 46-49 is illustrated as being implemented on different or separate workstations 
20-23 and 60 in Fig. 1, it will be understood that any or all of the implications 
associated with any of these various blocks could be implemented on the same or 
different workstations or other computers within or associated with the process plant 
10. Thus, the graphics editor 50 may be stored in and executed on any of the other 
workstations 20-23 or on any other computer associated with the plant 10 and need 
not be in a stand-alone or separate computer. 

[0052] As discussed above, the system level layer 44 of Fig. 2 implements system 
level display and database objects, which can be used in a variety of the functional 
environments as well as to provide higher level display capabilities. Generally 
speaking, the display objects created at the system level 44 of Fig. 2 can be 
categorized as graphic elements and graphic displays. Graphic elements are generally 
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primitive or low level display objects that are associated with a particular physical 
entity within the plant, such as a hardware device like a valve, a sensor, a pump, a 
controller, etc. Graphic displays are generally made up of a set of interconnected 
graphic elements and are used to represent and model more compUcated sets of 
hardware within a plant, such as a unit, an area, etc. and includes interconnections 
between different hardware units. Additionally, graphic displays may include graphs, 
charts and other data provided from the plant, from other applications, such as 
diagnostic and business applications running in the workstations 20-23 and 60, etc. 

[0053] Fig. 3 generally illustrates the development and use of graphic elements and 
graphic displays in two enviroDments in which these elements and displays may exist, 
in particular, a configuration environment 70 and a runtime environment 72. 
Generally speaking, display objects in the form of graphic elements 74 (depicted as 
separate element objects 74a, 74b, etc.) and graphic displays 76 (depicted as separate 
display objects 76a, 76b, etc.) are created in the configuration environment 70 using, 
for example, the display editor 50. After being created, the objects 74 and 76 may be 
stored in the database 52. The objects 74 and 76 may be created as class objects, 
referred to herein as display module class objects, which define a generic object not 
boxmd or tied to specific hardware or logical elements within the process plant 10. 
However, class objects can be used to create mntime graphical objects having the 
same basic properties as the class objects, but which are tied or bound to specific 
hardware within the process plant 10. Generally speaking, however, class objects 
remain tied to the children objects instantiated therefrom, so that changes to the class 
objects can be automatically propagated to the children objects, even when these 
children objects are instantiated within a runtime environmOTt. 

[0054] As illustrated in Fig. 3, each of the graphic element objects 74 includes a 
number of components that make the graphic element useftil in many different 
contexts. In particular, each graphic element 74 includes one or more visualizations 
77, any number of parameters or properties 78, any number of actions or animations 
79 which may be implemented using scripts or triggers, and bindings 80. Generally 
speaking, each visualization 77 defines the visual properties or elements to be actually 
displayed on a display screen when the graphic element 74 is implemented in the 
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runtime environment 72. Typically, visualizations define a rqpresentation of a 
physical or logical device or group of devices, although a visualization could 
represent other entities. Visualizations 77 may be implemented in the runtime 
environment 72 using any desired description or programming paradigm that defines 
the specifics of the graphical depiction of an entity. In one embodiment, the 
visualizations 77 may be implemented using PGXML or Avalon controls, which are 
well known controls provided by Microsoft® and which, because they are object 
based, provide a manner of making the visualizations easily implementable in 
standard Windows® type displays and portable between display environments. This 
feature will be discussed in greater detail below and is explained in co-pending 
application entitled "Markup Language-Based, Dynamic Process Graphics in a 
Process Plant User Interface" (Atty. Docket No. 06005/41 127), which is incorporated 
by reference herein. 

[00551 Generally speaking, the parameters and properties 78 define variables or 
other properties such as static or changeable intrinsic properties, associated with the 
entity being depicted by the visualization and these properties are definable by the 
creator of the element 74. Likewise, the actions and ammations 79 define routines or 
programs (which may be implemented as scripts which perform transforms on 
properties, which detect conditions of a process entity based on property values, etc.), 
animation routines which may include any routines that change the graphic 
visualization or behaviors to be performed on or using the visuaUzation 77 when the 
visualization 77 is depicted on a display screen, or routines which enable a user to use 
or interact with the visualization 77 to cause a change in the process, such as a change 
to an input to the process. These actions and animations provide the visualization 77 
with more interesting, imderstandable or helpfiil graphical properties and to allow the 
user to interact with the visualization 77. In one case, these actions or animations 
may take the form of changes in color, size (e.g., height and width, line size, fonts, 
etc.) of various components of the visualization, color fills, and animations such as 
changes in color, rotations, changes in size and scaling, skewing, etc. These actions 
and animations provide gi aphical properties as well as user interaction properties to 
the graphic element 74. The bindings SO, which may be static or fixed bindings or 
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bindings which use aliases, de&ie the manner in which the parameters or properties 
78 are to be bound to data, tags or other entities within the runtime environment 72 
when the graphic element 74 is implemented as part of a display in the runtime 
enviroiraient 72. Basically, the bindings 80 for each graphic element 74 estabUsh the 
manner in which the graphic element 74 is tied to one or more entities or data 
elements defined elsewhere in the plant environment, and thus define an interface 
between the actual runtime enviromnent 72 and the graphic element 74. 

[0056] As illustrated in Fig. 3, each of the graphic display objects 76 includes 
numerous components, such as a reference to or a copy of one or more graphic 
elements 81, connector elements 82, actions and animations 83, properties 84 and 
bindings 85. Generally speaking, a gr^hic display 76 may be a display that depicts 
the interaction of various graphic elements 81 which may be visually coimected 
together with connector elements 82 representing pipes, lines, conveyor belts, etc. 
Such connector objects are described in U.S. Publication No. 2004/0153804. A 
dotted line in Fig. 3 illustrates a reference to one of the graphic elements 74 by the 
graphic display object 76a. It will be imderstood that the graphic display 76 that 
references a graphic element 74 includes all of the properties, parameters, actions and 
animations, etc. of that graphic element 74. Similar to the graphic elements 74, each 
graphic display 76 may include one or more additional actions or animations 
associated therewith that perform, for example, animations on the display, user 
interface interactions, data manipulations, etc. Likewise, each graphic display 76 may 
include any number of properties associated with the display, and typically these 
properties define properties of units, areas, or other groups of elements dq>icted 
within the display. Of course, the bindings 85 define the manner in which the graphic 
display 76 is tied to one or more entities or data elements defined elsewhere in the 
plant environment and thus define an interface between the actual runtime 
environment 72 and the graphic display 76.. 

[0057] Once created, the graphic elements 74 and the graphic displays 76 may be 
bound to and executed in the runtime enviromnent 72 on, for example, any of the 
workstations 20-23 of Fig 1. In particular, after a graphic element 74 or a graphic 
display 76 is created as a class object and is stored in the database 52, that element or 
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display may be instantiated as an actual runtime object and may be executed in the 
runtime enviromnent 72. As illustrated by the block 86, the instantiation process fills 
in the bindings defined in the objects 74 and 76, which may be accomplished using 
one or more resolution tables that may be loaded with proper variable names, tags, 
ahases etc. within the process plant or process control system to provide a specific 
connection between actual entities within the process plant and the graphic objects 
running on a display device within the plant 10. As part of the binding process, the 
objects 74 and 76 connect to data sources within the process plant as defined by the 
resolution table, and thereby gain access to the plant so as to be logically and 
communicatively connected to the process plant 10. 

[0058] As illustrated by the blocks 87, a display element 74 or a gr^hic display 76 
can be executed in or as part of a number of different functions within the runtime 
environment 72, including a configuration display, a control operator display, a 
maintenance display and a simulation display, to name but a few. Additionally, the 
display objects 74 and 76 may be used in performing system level fimctions. e.g., 
ones that use data fix>m various ones of the fimctional levels depicted in Fig. 2, 
including for example, predictive control or predictive maintenance fimctions, system 
level error detection, diagnostics, etc. In fact, the displays 76, once created in the 
configuration environment 70 and stored in the database 52 may be used for a number 
of different activities. Still further, the display objects 74 and 76 may be^xecuted on 
any desired display or computer hardware, such as a workstation 90, a laptop 
computer 91 , a handheld device 92, like a personal data assistant (PDA), a telephone 
device, etc., or any other specialty display 93, such as a large screen display having 
multiple monitors, etc. If desired, a single graphic display 76 may be layered to 
include one or more views, such as configuration view, an operator view, a 
maintenance view and a simulation view. Alternatively, separate graphic displays 76 
may be configured to provide these separate views using the same or similar graphic 
elements 81, to provide a consistent look and feel across displays created for these 
various functions. 

[0059] As illustrated by the block 95, to be ported to the runtime environment 72, a 
graphic element 74 or a graphic display 76 may be copied or instantiated, and loaded 
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onto the runtime machine. Generally speaking, it is desirable that the display object 
74 or 76 be bound to the runtime environment 72 only when called up or actually 
executed on a runtime machine, which is referred to herein as runtime binding. That 
is, the resolution table for each of the instantiated objects is only filled in or bound to 
the runtime environment when the display object is actually miming or being 
executed in a runtime computer. This procedure assures that the display object 
including its visualizations, controls, scripts, etc, only executes and thereby uses 
processing power when the visualization(s) of the object are actually being rendered 
on a di^lay screen. Thus, the display object is preferably only bound to the runtime 
environment 72 when that object is actually running on a runtime computer, which 
means that the display objects 74 and 76 may be intermittently connected to the 
runtime enviroEonent 72 in a maimer defined by the activities of the users viewing the 
visualizations created by these objects. In particular, these objects may be bound to a 
runtime environment 72 at the times at which they are required to be viewed, and may 
be unbound or released when not being viewed by a user, such as when a user 
minimizes or closes a screen in which these objects are providing a visualization. 

[0060] The display objects 74 and 76 are thus objects which may be created in a 
stand-alone environment, i.e., Ilie configuration environment 70, but which may be 
tied or connected with other objects or data structures defined within the process plant 
environment or any application running within the process plant enviroimient, 
including, for example, objects, data stractures, s^plications, etc. defined in any 
control, simulation, maintenance, or configuration environment. Fiirthermore, once 
created, the display objects 74 and 76 may be bound to physical or logical process 
entities directly, via direct references, variables or tags defined a resolution table, or 
indirectly through the use of alias names, variables and parameters, which may be 
resolved either when the display object 74 or 76 is downloaded or instantiated within 
the a runtime environment 72, or in some cases, when the display object 74 or 76 is 
actually running within the runtime environment 72. 

[0061] The display editor 50 of Fig. 3 may enable the display objects 74 and 76 to 
be created at various levels of detail, to enhance the ease of use and the versatility of 
the display objects 74 and 76. For example, graphic elements 74 may be created first 
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to define the properties and operations of more primitive physical and logical entities, 
and graphic displays 76 may then be created by interconnecting one or more gjraphic 
elements 74 to create higher level or more complicated displays depicting more 
complicated physical or logical entities, or groups of physical or logical entities. Of 
course, both graphical elements 74 and graphical displays 76 may be stored and 
accessed in various different categories, to make the creation of higher level display 
objects more simple to the user. 

[0062] Fig. 4 illustrates an example screen display 1 00 that may be oreated by the 
display editor 50. The screen 100, which is depicted in the process of creating a 
graphic element for a pump, includes a main edit section 102, an element hierarchy 
section 104, a property definition section 106 and a visualization section 108. The 
main edit section 102 provides a working space for the user or designar to define or 
create a visualization for the graphic element and thus to define the visual properties 
of the graphic element, in this case a pump illustrated vsdth a visualization 109. 
Generally speaking, the element hierarchy section 104 provides, using a hierarchical 
view or a tree structure, the components associated with the visualization 109 within 
the main edit section 102. In the example of Fig. 4, the hierarchy section 104 shows 
that the visualization 1 09 being defined in tiie main edit section 102 includes 
primitives or sub-eleanents of a circle (named Circlel) and two rectangles (named 
Recti and Rect2). While not shown in Fig. 4, the hierarchy section 104 may include 
indications of animations, actions and other display features, such as scripts, visual 
triggers, etc. defined for the visualization 109. 

[0063] The property definition section 1 06, illustrates all of the properties, 
including intrinsic properties, currently defmed for the graphic element associated 
with the visualization 109 shown in the edit section 102. The example screen 100 of 
Fig. 4 illustrates two properties including an IsOn property, which defines whether the 
pump associated with the visuaUzation 109 is on or off, and a Speed property, which 
defines the speed of the pump associated with the visualization 109 . The user or 
designer could add other properties and parameters to the graphic element by defining 
the names, types and bindings of other variables, properties, etc. within the property 
definition section 106 to thereby define other aspects of the graphic element. The two 
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properties shown in the section 106 of Fig. 4 are listed as being Boolean and floating 
point variables. However, other types of variables could be used instead or as well. 
Thus, for example, the properties defined in the section 106 could be arrays, tables, 
enumerated lists or any other types of variables or data structures. 

[0064] If desired, the graphic element being defined within the screen 100 may 
have multiple visualizations associated therewith- The different ones of these 
visuahzations may be depicted in the visualization section 108 and may be selected 
individually to be placed into the main edit section 102. For example, two 
visualizations 1 lOA and 1 lOB are shown in the visualization section 108 of Fig. 4, but 
any other number and type of visualizations could be defined for the graphic elemrait 
being created. During the graphic element creation process, each visualization may 
be placed in the main edit section 102, such as by right clicking or double clicking on 
an indication of the visualization in the section 108, dragging and dropping the 
indication of the visualization onto the edit section 102, etc. Once placed in the main 
edit section 102, a visualization may be edited to define or re-define its display 
properties. Generally speaking, one of the visualizations will be set or defined as the 
default visualization for the graphic element being created. This default setting may 
be indicated in some manner, such as by the default visualization being highligjited, 
surrounded with a dotted line in the visualization section 108, as illustrated for the 
visualization 1 1 OA in Fig. 4, or in any other maimer. 

[0065] Generally speaking, the visualizations created by the element editor 50 may 
be made up of one or more composites of various shapes which are placed or grouped 
together in a defined manner. These visualizations may, therefore, be referred to as 
shape composites. For example, shape composites may include circles, lines, points, 
polygons, squares, rectangles, triangles, or other simple graphic shapes. When 
defined in this manner, separate actions or animations may be applied to or associated 
with each of the different shapes making up a shape composite. Of course, shape 
composites may include more elaborate artistic renditions of elements. To define or 
build up a shape composite, a user or designer may add any number of primitive 
graphic elements to tlie main edit section 102 and group these primitives together in 
any desired manner. Once created, shape composites define the visualization for an 
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actual object, which might be implemented in the runtime as an XAML object, that 
will be displayed on a screen or display as a visualization when the graphic element is 
used in a runtime environment. The shapes or primitives making up the shape 
composite may illustrated in a composite hierarchy in the hierarchy section 104. 

[0066] The creation of multiple visualizations for a single graphic element enables 
different visualizations to be used in different contexts or for different uses, so that 
displays created for the different purposes within the plant may be created from the 
same gr^hic element (i.e., created from fhe same graphical class object) while 
displaying different visualizations of a common element For example, different ones 
of the visualizations 1 1 OA, 11 OB, etc. may be used in different functional contexts, so 
ttiat a first visualization 1 1 OA may be used when the graphic element is used as part 
of a control operator's display, a second visualization 1 lOB may be used when the 
graphic element is used as part of a maintenance display and a third visualization (not 
shown) may be used when the pump element is used in a simvdation display. On the 
other hand, different visualizations may be used for display purposes on different 
types of display devices. For example, a first visualization of a graphic element may 
be suitable for use on a typical computer or workstation, while a different 
visualization may be created to be advantageously used on a handheld device, like a 
PDA or a telephone device, while a still fiirther visualization may be created for large 
screen displays, or a multiple screen monitor. As will be understood, different 
visualizations for a graphic elanent may be tailored based on the size of the display 
on which fho visualization is to be displayed, so that a first visualization may be 
created that is suitable for a larger screen, such as a typical computer screen, and 
second visualization may be created that is more suitable on a screen that is 
significantly smaller, such as a display screen of a handheld device, like a PDA or a 
wireless telephone device. Thus, different visualizations for the same gr^hic element 
may be used in different runtime devices. 

[0067] On the other hand, different visualizations may be added to tiie graphic 
element at different times in the development cycle of the graphic element. For 
example, a configuration engineer, who may not be adapt at drawing or producing 
pleasing visualizations, may produce a first, primitive visuaHzation that is preliminary 
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and basic in nature (such as a stick figure type drawing) when first creating the 
graphic element and may store this visualization as part of the graphic element at that 
time. At a later date or time, a skilled draflsperson or artist may create a more 
elaborate and artistically pleasing visualization and can add that second visualization 
to the graphic element as an altemative visualization. If desired, at that time, the 
second visualization can be set as the default visualization, and this second 
visualization can be propagated throughout all of the runtime graphic elements that 
have been instantiated firom the master or class graphic element, so that this second 
visualization shows up in or is available for use in the runtime displays. 

[0068] In another example, different visualizations may be provided for flie same 
graphic element to support different themes, graphical standard, norms or styles of 
displays. As is known, different industries typically use different graphic norms or 
graphical standards for depicting pumps, valves, sensors, and other process plant 
entities. Thus, the oil and gas industry uses different graphical standards than does 
the pharmaceutical industry. Using the element editor 50, it is possible to provide 
different visualizations for each graphic element to support multiple graphical 
standards or norms, such as the oil and gas nomi and the pharmaceutical norm. In this 
manner, the same graphic element may be used in graphic displays created to support 
different standards or norms or themes of displays,- e.g., displays acceptable or useful 
in different industries. Still further, different graphical styles, such as artistic styles 
may be used in different visualizations to enable a user to create displays of various 
artistic types. Of course, these are only a couple of examples of the benefits of 
providing multiple visualizations for the same graphic element, and other uses for 
these multiple visualizations exist as well. 

[0069] If desired, the graphic element may have one or more graphical behaviors 
defined or associated with it. In particular, a designer or creator may define 
animations, such as rotations, linear translations, background changes, color changes, 
resizing, color gradient animations, opacity animations, font characteristic animations, 
videos and video features, such as start/stop features, two-dimensional or three- 
dimensional changes, etc. for each visualization of the graphic element when the 
visualization is displayed on a screen. To add this dynamic behavior, the user may 
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select a graphic element and opt to add an animation (also called an animation 
routine) to the visualization. At this point the user may enter configuration 
mformation pertaining to the selected animation or may define the desired behavior 
using scripts, which may be entered using, for example, dialog boxes, expression 
editors, etc. When defined, these scripts may show up in the hierarchy of the 
hierarchy section 104. Basically, a script is a program or routine that will run or 
execute as part of the display element when the visualization for the display element 
is being viewed or presented on a screen durmg a runtime activity. Although it is not 
necessary, these behaviors or scripts may be tied to and operate on one or more of the 
properties or parameters defined for the graphic element. For example, a script may 
be associated with a graphic element to change a color witiiin the visualization of the 
graphic element based on the value of one of the properties defined m the property 
section 106 of the graphic element. For example, the^;olor of the pump visuaKzation 
109 may change from yellow to green when the IsOn property (wHch is boundto the 
runtime environment) is True, i.e., when the pump is turned on. As another-example, 
a script may be defined for the pump element that compares the value of the Speed 
property of the pump to a set point and. if the value of the Speed property is above a 
certain level, causes a graphic animation of some kind within the visualization 109. 
. This animation may include, for example, turning the pump red, rotating the pump, 
showing a motor within the pump rotating, causing the pump visualization to pulsate 
or vibrate, etc. 

[0070] The scripts defined for a visualization to, for example, provide animation 
or other behaviors for the visuaUzation, may be designed to operate on individual ones 
of the shapes or primitives within a shape composite making up the visualization, or 
on multiple ones of the shapes within the shape composites. Because the scripts 
operate on or use the intrinsic properties, which are bound to actual physical elements 
in the runtime environment, these scripts enable the yisuahzation to change based on 
actual plant operations, or based on data from other areas of the process plant that 
reflect the properties of an actiaal entity associated with the graphic element. 
[00711 it will be understood that different types of graphic elements may have 
different graphics that may be appropriate for use tiierewith. Thus the behaviors that 



wo 2005/109130 



PCT/US2005/015942 



may be provided for a graphic element are not limited by the examples provided 
herein. For example, graphic elements for rotating equipment might include scripts 
that provide vibrational graphics, movement, color changes, etc., while graphic 
elements for equipment such as sensors may include scripts that depict an over or 
under limit condition, a need for calibration condition, etc. Of course, any properties 
may be used or defined for graphic elements and these properties will generally be 
based on the type of entity being represented. It will also be understood that various 
scripts may be provided for each of the different visuaUzations, to provide different 
behaviors for the different visualizations. On the other hand, some scripts may be 
used to provide behavior for each of the visualizations associated with a graphic 
element. 

[0072] Additionally, scripts or other routines may be associated with a graphic 
element to detect certain conditions about the associated physical entity based one or 
more of the parameters for the graphic element. These conditions may include 
detecting states of the entity, including a physical state, a status Uke a communication 
status, a device status, a value status, etc. associated with the entity. All these 
detected conditions or states may be reflected on the graphic using an animation or 
other action or behavior tied into the state or value produced by the script. For 
example, a script may be provided for a pump graphic element that detects an 
overheating condition of the associated pump based on one or more parameters for 
that element, that is, one or more of the parameters defined or exposed in the property 
section 106 of Fig. 4. As another example, a script may be provided for a graphic 
element to detect excessive vibration, or any other condition of the pump. If a 
condition, such as overheating or excessive vibration, is detected, an animation or 
other action associated with tiie graphic element may operate on the condition to 
provide a graphical indication of the condition within or on the visualization of the 
graphic element. 

[0073] Fig. 5 illustrates another example screen display 112 that may be produced 
by the display editor 50. Similar to the screen 100 of Fig. 4, the screen display 112 
includes a main edit section 1 1 4, a pallet view 1 16, a hierarchy view 118 and a 
property view 120. A first visualization of a reactor element 122 is depicted in the 
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main edit section 114. As shown in the hierarchy view 1 18, the title of the element is 
Reactorl and this element includes three visualizations named Visuall (the default 
visualization), Visual2 and VisualS. As indicated beneath the Visuall heading in the 
hierarchy view 1 18, the first visualization is made up of a Canvas background which 
includes a rectangle element and an ellipse element. The currently defined properties, 
in this case a name, a height and a width of the visualization, are list-ed in the property 
view 120. When a visualization is selected in the hierarchy view 118, any of the child 
primitives or elements associated with the visuaUzation are shown in the^dit view 
1 14 and the properties of the currently selected element are displayed in the property 
view 120. 

[0074] In the screen 1 12, the pallet view 1 16 includes a number of basic elements 
that can be used to create a visualization. For example, the pallet view 1 16 includes a 
set of basic UI (user interface) elements, such as buttons, text boxes, sliders, knobs, 
etc., a set of basic panels, and a set of basic shapes. The defined panels may include a 
canvas panel which defines an area in which the user can explicitiy position elements 
by coordinates relative to the canvas area, a dock panel which defines an area in 
which the user can arrange elements either horizontally or vertically relative to one 
another, and a flow panel which may be used to break, wrap and align its content 
within a flow panel area with a flow direction indicated. Flow directions niay be, for 
example, any combination of top, right, left and bottom, such as left to right and top to 
bottom, or right to left, top to bottom, etc. Still fiirther, the basic shapes in the pallet 
view 1 16 may include ISA (Instrument Society of America) symbols, transmitter 
symbols, valve symbols, PI&D diagram symbols or other control symbols, etc. or any 
other desired shapes, all of which can be used to build a graphic element. 

[00751 Of course, other basic elements, such as basic control elements, devices, etc. 
may be provided as primitives in the pallet view 1 16 to be used to create 
visualizations for a graphic element being defined. The pallet view 1 16 may also 
provide a list of user defined categories or elements, which may be created to allow 
users to drag any other usefiil shapes firom the pallet view 1 16 to the edit view 114. If 
desired, access to such user defined categories may be limited to the users who create 
them and these categories and elements may be stored in a user preference file 
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associated with a particular user. However, built in categories and pallet items may 
be stored in the database and may be available globally to all users. In any event, the 
pallet view 116 may be used to display or provide access to libraries of primitive 
elements that may be used to make up a graphic element, and these libraries can be 
locked, versioned, limited to particular users, etc. as desired. 

[0076] As noted above, any of the visualizations for a graphic element can have 
animations and/or actions associated therewith, and such animations or actions may 
be shown in a action/animation view 123 of tiie screen 112. When visualizations 
include animations or actions, these animations oi: actions can also be indicated in the 
hierarchy with special symbols such as stars, etc. When selected in the hierarchy 
view 118, any actions or animations defined for a visualization or a sub-element of a 
visualization will be shown in the action/animation view 123. Actions or animations 
may be created and assigned by defming such actions or animations in the view 123 
or by adding such actions or animations to the hierarchy view 118. When a user 
wishes to create or edit an action or animation, the editor 50 may provide a dialog or 
edit box to allow this feature to be fully specified or defined. Of course, actions or 
animations may be defined using scripts, visual triggers or other programs. 

[0077] During use of the screen 1 12, a user or designer may create a visualization 
of an element by dragging and dropping or otherwise selecting different items in the 
palette view 116, and arranging these items in the edit view 1 14 to create the desired 
visualization. One or more toolbars 124 can be used to provide any standard editing 
functions such as adding new visualizations or animations, deleting, removing, editing 
animations, arranging primitives or elements fi-om for example backward to forward, 
providing for connection elements to show or enables connections to be made to the 
visualization being created, grouping different primitives together so that they hold 
their position relative to one another, adding static elements like lines and text, etc. 

[0078] As illustrated in Fig. 6, a graphic element 130 may have multiple 
visualizations 132 or visual representations associated therewith, it being imderstood 
that the different visualizations 132 may be used at different times or in different 

displays in wliich the grapliic element 130 is used. As explained above, any of the 
visualizations 1 32 may be made up of any number of primitives 134 as well as 
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animations and actions 136. Still further, the gr^hic element 130 may include any 
number of properties or parameters 138, which may be tied into or used by the actions 
and animations 136 to perform changes to the visualizations 132 and to operate visual 
triggers associated with the visualizations 132. Still further, the visualizations 132 or 
individual primitives making up a visualization 132 may have actions defined for. 
predefined events, for example, mouse over events, mouse click events, etc. These 
actions (which are also referred to as routines) enable event handlers to be set or 
defined to further customize the behavior of the graphic element 130 and to allow a 
user to interact with the visualization 132 to, for example, cause a change within the 
runtime environment. In particular, the user may interact with the visualization 1 32 
by entering values or other numbers or information therein, moving an element on the 
visualization, such as a slider bar, or by taking some other action to change, for 
example, a property within the visuaUzation. This visualization property change may 
be tied, via a script or directly, to a process input, such as a process runtime variable 
to cause that variable to change. In particular, the visualization property may be 
connected to a property defined for the graphic element which, in turn, may be bound 
to a process input. In this manner, a user may interact with the visualization via an 
action or animation routine to cause a change or to provide an input to the process or 
other runtime environment, such as a simulation environment. 
[0079] If desired, a visualization 132 may be connected to the gr^hic elranent 130 
either by being specified by a user or by being specified programmatically. In 
particular, the gr^hic element 130 may expose an enumeration property that allows 
the visualization to be programmatically changed based on, for example, the 
manufacturer of the element being represented by the graphic element, or ottier 
parameters associated with the graphic element 130, such as the state of the device 
associated with the graphic element, 

[0080] As noted above, the properties view 120 of Fig. 5 provides or shows the 
properties and events defined for the selected item in the hierarchical view 118 and 
tlius for the item depicted in the main edit view 1 14. A user may toggle among 
properties, intrinsic properties and events within the properties view 120 using, for 
example, toolbar buttons. Fig. 7 shows a property view 120A in which the intrinsic 
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properties are shown, in this case including an IsOn and a Speed property. In this 
case, the properties view 120A shows the data type of these variables and any default 
settings for these variables. As noted above, the user can add to, delete from or edit 
this property Ust to define properties with any desired data type, including 
enumerations, table structures, etc. If desired, the properties view 120 may also show 
any runtime bindings defined for these properties and these runtime bindings may be 
fixed variables or tags or may be tags using aUases that are filled out at runtime or 
downloading of ttie graphic element to a runtime machine. 

[0081] The values of the properties defined for a graphic element can be used as 
triggering conditions for animations, actions, etc. and these behaviors may be defined 
by one or more scripts associated with the graphic element. For example, if a motor 
has an On property that is true, then an animation of the motor operating can be 
triggered in the graphic display. Still further, a primitive property, for example, a 
rectangle fill property of a primitive in the form of a rectangle, can be bound to a 
graphic element property so that changes in the graphic element property effect the 
primitive property. likewise, changes to a visualization may be tied to a property, so 
that changes to the visualization may cause changes to the property value. 

[0082] If desired, the editor 50 may enable a user to specify one or more 
transformer functions to provide more desirable bonding between graphic element 
properties and animations or actions. For example, a user may wish to bind a graphic 
element property of TankLevel (defining a level of fluid within a tank) to a primitive 
property rectangle fill, to thereby graphically illustrate the tank level with a fill color 
for a primitive defined as part of the visuaUzation. However, in this case, the user 
may define a transformer fimction that transforms the property (the TankLevel) into 
an enumerated set or condition, so that if the tank level is between a first and second 
level, the rectangle fill is set to green, if the tank level is between the second and a 
third level, the rectangle fill is set to yellow, and if the tank level is greater than the 
third level, the rectangle fill is set to red. This transformer fimction may be defined as 
a script or as any other program that executes with the graphic element and may be 
used to cause any desired property transfomiation, such changing a property value to 
a length, a font name, a localized string, a duration, a rotation, a color gradient, an 
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opacity, a brush pattern, etc. Likewise, transform routines may transform inputs from 
a user via the visualization to any desired property values. 
[0083] As another example, graphic element properties or parameters may be 
bound to external references using transformer ftinctions. Here, the editor 50 may . 
allow a user to specify one or more transformer functions that will be automatically 
appUed when the gr^hic element is used in a runtime environment to convert source 
values (runtraie variables) to destination values (graphical variables) or vice-versa. 
For example, a speed destination variable, which might be bound to a data source that 
provides a speed as a numerical value, could be converted to a string type variable, 
such as a string indicating one of "slow." "moderate" and "fast," based on the value of 
the source variable. Such transform functions may also be used to convert units, or 
provide other transformations. In any event, these transform functions may be 
implemented as scripts or other programs and can be used for any purposes to provide 
actions or animations or to otherwise affect display properties for a graphic element. 

[0084] Of course, any desired properties may be defined for different types of 
graphic elements created for dififerent physical elements within a process control. For 
example, a pump element may include a pump state (e.g., on or off) a pressure-in 
property, a pressure-out property, a flow-in property and a flow-out property. 
Likewise, a regulating valve used with an actuator may include, for example, a name 
property, a density-in property, a density-out property, a flow-in property, a flow-out 
property, a pressure-in property, a pressure-out property, a temperature-in property, 
temperatiu-e-out property, a valve position property, a valve-open and valve-closed 
property (which may define if the valve is all the way open or closed), a set-point, a 
process value, a valve type, such as linear, quick opening, equal percentage, etc.. This 
list is not, of course, intended to be comprehensive. Still further any of these 
properties can be coimected to animations or actions for graphic element. 
[0085] Fig. 8 depicts a second property view 120B which may be used to view the 
animations and bindings associated with graphic element properties for a selected 
element (in this case the Reactorl element generally) within the hierarchical view 118 
(Fig. 5). The properties view 120B of Fig. 8 illustrates the manner in which the IsOn 
property relates to various components of the visual for the graphic element. In 
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partictdar, as indicated by the table entry 140, there is one animation that is related to 
the background of the visualization and that operates based on the value of the IsOn 
property. A table entry 142 shows the bindings between the IsOn property and may 
be used to access animations, scripts and transforms that relate the IsOn property to 
the background element or primitive within the visualization. In this case, the user 
may obtain additional information by selecting the buttons in the table entry boxes 
140 an 142. For example, by selecting the button in the table entry 140, the user may 
access an animation that causes the background of the visualization to change color 
based on the value of the IsOn parameter. Clicking on such an animation button may 
also cause tiie editor 50 to open a property animation dialog box which allows for 
management and configuration of the animations. Still further, binding can be 
performed and managed by clicking on a binding button in the box 142, wMch causes 
the editor 50 to open a dialog box to enable creation, viewing and editing of bindings. 
Of course similar screens could be provided for other properties of the gr^hic 
element and the list of properties that are shown in the property screen 120B will be 
dependent the cvmrently selected item in the hierarchy view 118. 

[0086] Referring again to Fig. 5, when a visualization is selected in the hierarchy 
view 118, tiie properties view 120 will display the visualization properties, such as a 
name, an LD. which provides a unique identifier for the visualization, a description 
and whether this visualization is set as the default visualization for the gr^hic 
element. The hierarchy view 1 1 8 or the property view 120 may also indicate whether 
tide visualization is locked, i.e., whether it can be modified. 
[0087] Additionally, when a connector element is selected fi-om the hierarchy 
section 1 18, the properties view 120 will show the properties of that coimector 
element, which may include an indication of the connector type (e.g., a fluid line, an 
electrical line, a gas line, a circular or square duct, a conveyor belt, etc.), whether the 
connection is into or out of the device (i.e., the du-ection of flow of material with 
respect to the entity being represented by the ^aphic element), the minimal and 
maximum number of connections required or allowed, tlie width and height of the 
connection, the position of tlie connection with respect to the gr^hic element, such as 
on top, the left, etc. 
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[0088] When a primitive is selected in the hierarchy view 1 1 8, the properties view 
120 will display the properties of that primitive, which may include for example, an 
I.D., a category .description, whether the primitive is selectable and/or visible, a size 
and length or other definition of tiie shape or nature of the primitive, a background 
color and the fill space for the primitive, etc. Of course, any other selected item 
within the hierarchy view 118 will cause the properties of that item to be displayed in 
the properties view 120, and the type and nature of the properties will be dependent 
on the nature of the selected item. 

[0089] If desired, an event sheet may be provided to show the events associated 
with each or all of the selected luerarchy items within the hierarchy view 118. Such 
an event sheet could include events that occur when a user performs an action with 
respect to a graphic elements, such as an "on-click" event and an "on-mouse-over 
event" which define what happens when a user clicks on a visualization for the 
graphic element or a portion thereof, or what happens when the user positions the 
mouse cursor over the visualization of the graphic element, or a portion thereof. As 
part of this event sheet, a user may be provided access to a script editor to define or 
access a script that wiU be run upon the occurrence of the event (which is defined 
herein as a routine). 

[0090] Additionally, if desired, graphic elements can have custom events 
associated therewith. Custom events are generally events that are defined as a result 
of some outside or exterior event, or are events that require communication with an 
exterior application or data source as a result of an action taken by a user of the 
graphic element. Essentially, a graphic event is a message that is sent by the graphic 
element to signal the occurrence of an action with respect to the visualization of the 
graphic element. The containing or runtime appUcation implementing the graphic 
element can catch these events using, for example, a C# syntax or by registering to 
event notification in any known manner. In one example, the containing appUcation 
may register to a pump over-heat custom event and provide a my-handler fiinction 
that will run a script or other routine to enable a user to handle the event, when it is 
triggered. These custom events are particularly usefiil when the graphic element is 
implemented as part of a control operator screen. In this case, the graphic element 
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itself may determine an event condition, such as by comparing a pump heat property 
(which is bound to an external measurement) to a set-point or other limit, and may 
trigger an event response by notifying the user of the event and implementing an 
application, script, dialog, etc. to enable the user to handle or deal v^th the event, in 
this case, an overheating pump. To enable this event handling process, the element 
editor 50 will allow a user to define event arguments, i.e., what is recognized as an 
event and what results firom the occurrence of an event. 

[0091] Of course, if desired, graphic elements can provide standard events inherited 
from an Avalon control class. As is known, the Avalon objects or controls are 
Microsoft defined graphics for the Avalon user interface architecture for the 
Microsoft Longhom operating systan, which support the rendering of vector graphics 
on a user interface. These standard events may include, for example, tying the 
viewing of a faceplate display or a device detail display to a click or a double click 
(mouse) event. For example, a chck or double click event, which is an event 
reporting a mouse click or double click within the boxmds of the visualization of the 
graphic element, can trigger the display of a faceplate or detail display for the device 
or entity being represented by the visualization and provides the user with more 
complete or thorough information about the state, design, manufacture, etc. of the 
entity being represented. Of course, other events, including standard events, may be 
defined for a key down/up event, which is an event reporting that a key was pressed, 
mouse events, which include mouse enter, mouse hover, mouse move, mouse wheel, 
etc. actions, or any other user initiated events. 

[0092] Thus, if desired, graphic element events may be triggered within the script 
of an event handler, such as in the event handler for a primitive event, or within a 
transformer fimction, upon changes within a property of the graphic element. Still 
fiirther, primitives of a graphic element may expose events which can be triggered by 
user interactions with them, for example, through the mouse and keyboard. These 
events provide options for the user to interact with the graphic element at the shapes 
and primitive levels. Developers can handle the events internally within the graphic 
element by specifying event handlers using C# methods, for example. 
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[00931 Referring again to Fig. 5 the actions/animation view 123 may provide or 
show a list of transform animations and property animations defined for the 
visualization currently being displayed in the edit view 1 14. A user may, for 
example, double click on a row within the view 123 to cause the editor 50 to present a 
dialog box, which might be a transformer animation dialog box or a property 
animation dialog box, which allows the user to edit the selected animation. Typically, 
only the animations of the currently selected visualization will be shown, but selecting 
a Show- All box 144 could show animations and actions for all of the visualizations. 
Assuming that animations are provided with meaningful names or descriptions, for 
example, "animate lever," ''rotate motor," etc., the action/animation view 123 
provides for easy viewing and access to animation behaviors defined for a 
visualization. Fig. 9 illustrates an example actions/animations view 123A which 
illustrates the actions defined for the IsOn property. In this case, when the IsOn 
property is 'True", the primitive <;alled Rectanglel of the visuaUzation called Visuall 
implements a fill action with the fill value of "red." Lflcewise, when , the IsOn 
property is "True", the primitive caUed ElUpsel of the visualization caUed Visuall 
implements a visible action with the value of false (e.g., becomes invisible). Of 
course, actions and animations may be defined separately for separate primitives of a 
visuaHzation, but these actions and animations may operate simultaneously upon the 
same event, trigger or property change to present a more complicated but pleasing 
animation. Still further, actions and animations may include performing single 
operations, such as increasing size, filling color, etc., or repetitive operations that 
occur continuously until tumed off. 

[0094] Fig. 1 0 illustrates a manner in which a visual trigger 1 48 can be 
implemented on a visualization 150 of a graphic element 1 52 based on the properties, 
such as intrinsic properties, of the grapliic element 152. In particular, one or more of 
the intiinsic properties of the graphic element 152 are monitored by one or more 
property triggers 154 (three of which are shown in Fig. 10) defmed for the visual 
trigger 148. Each property trigger, which may be implemented using a script, can 
monitor for certain graphic element property values as shown by the dotted line 155. 
Thereafter, each property trigger can set one or more primitive property values of the 
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visualization 150, as illustrated by the dotted lines 156, when the monitored graphic 
element property value is satisfied or meets a specified condition. Thus, for example, 
one of the property triggers 154 may monitor one or more graphic element properties 
to determine when a value of one or more of these properties falls within a particular 
range. When this condition is met, the one of the property triggers 154 may cause an 
animation or other visual script to be run on, for example, a primitive or other element 
of the visualization 150 to provide the visual trigger 148. Of coxirse, multiple ones of 
the property triggers 154 may operate togefhCT to provide multiple simultaneous 
changes or animations as part of the visual trigger 148, or different ones of the 
property triggers 154 may operate independently on, for example, different intrinsic 
properties or based on different values of the same intrinsic property, to provide 
different operations of the visual trigger 148 at different times or in response to 
different process conditions. In this manner, color changes, animations etc. can be 
provided in the visualization 150 based on the values of the intrinsic properties of the 
graphic element 152. 

[0095] If desired, the editor 50 may provide or display a visual trigger panel listing 
all the property triggers for a currently selected visualization. Such a panel is 
illustrated in Fig. 9, in which the element property column lists the gr^hic element 
property name, the first value column indicates the graphic element property value 
being watched, the target column provides a visualization or a primitive identification 
which will be changed, the path column is the primitive property being changed and 
the second value column is the primitive property to apply when the graphic element 
property value being watched is satisfied. Of course, animations and other 
visualization changes may be provided using this structure. 

[0096] Fig. 1 1 illustrates a transform animation dialog box 160 which may be used 
to help or enable a user to specify a transform animation. As illustrated, the transform 
animation dialog box 160 includes a move section 162 which allows the user to 
specify a direction and a distance in terms of pixels defining a movement within an 
animation, a rotate section 1 64 which allows a user to specify a rotational direction ♦ 
and an angle for the animation and a scale section 166 wliich allows the user to 
specify a degree of scaling for an animation, both in the horizontal and vertical 



-40- 



wo 2005/109130 PCT/US2005/015942 



directions, and to specify whether the aspect ratio should be locked. The dialog box 
160 also includes a skew section 168 which allows the user to specify a skew to be 
appUed during an animation, both in the horizontal direction and the vertical direction. 
A settings section 170 allows a user to define if the animation is to be continuous or 
not, and to enable each of the other move, rotate, scale and skew actions. Still further, 
a preview box 1 72 may illustrate a preview of the animation. 

[0097] As will be imderstood, an animation is an object that changes in value over 
a period of time. A property animation may be achieved by associating an animation 
with a primitive property. Property animations can be as subtle as causing the color 
of the text to change, or to cause an element like a line to blink. On the other hand, 
property animations may be more complex, such as animating the points of a poly 
line, etc. Of course, these are but a few examples of animations, and other animations 
may include adding or changing colors, changing the size (such as the widtii, lengtii or 
point size) of a piimitive, movmg, rotating, skewing, scaling primitives, etc. Still 
further, other animations could be provided at any level of tiie visuaUzation, such as at 
the primitive level or as part of the entire visualization. Of course, multiple 
animations can be provided or applied to any particular visualization or to any 
particular primitive of a visualization if so desired. Still further, multiple animations 
associated with a particular visualization or a primitive of a visualization may operate 
simultaneously or at different times based on changes in property values or based on 
user initiated triggering events, such as mouse events. 

[0098] Fig. 12 illustrates a property animation dialog box 180 that may be 
produced by the editor 50 to enable a user to define or change a property of the 
animation to thereby define tixe animation. The dialog box 180 includes a bounds 
definition section 182 and a timeline definition section 184. The bounds definition 
section 182 provides or defines the bounds of the animation. In particular, a "firom" 
property defines the starting value of tiie animation and a "to" property defines tiie 
ending value of the animation. The timeline definition section 184 defines a duration 
for the animation, a begin time and an end time for tiie animation. The duration 
property defines the length of time that the animation takes to complete, the begin 
time property defines a time offset with respect to the start time of the animation and 
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the end time property defines the end time of the animation with respect to the start 
time. A speed definition section 186 allows a user to specify a speed, an acceleration, 
and a deceleration using, for example, sUdebars. As will be evident, the speed 
property defines the speed of the animation, the acceleration property makes 
animation move faster with respect to increasing time while the deceleration property 
makes the animation move slower with respect to increasing time. A repeat definition 
section 188 allows a user to define the manner in which the animation will repeat, 
e.g., for a specified number of times, for a specified count or duration or continuously 
imtil turned off. 

[0099] A further animation dialog box 190, which may be accessed through the 
dialog box 1 80, may be used to specify different colors to be used as bounds in the 
animation when using the boxmds definition section 1 82. Similar dialog boxes may be 
used to enable the user to select other non-numeric values as properties of an 
animation. While not shown, other animation properties may be selected or specified 
as well using this or other dialog boxes. For example, an auto reverse property may 
be used to define a Boolean value that indicates whether the animation plays in 
reverse after it completes its forward direction and a "by property may be used to 
define the total amount by which animation changes its starting value. A relative 
speed property may be used to define a relative speed at which time passes for the 
animation as compared to parent animations, i.e., animations associated with parent 
elements of the visualization. A value of 1, for example, may indicate that ttie 
animation progresses at the same speed as the parent animation, a value of 2 may 
indicate that the animation progresses twice as fast as its parent animation, and so on. 

[0100] While not shown, dialog boxes can also be used to set the font properties of 
an animation, such as the style, the size, the font, and the color of text within the 
animation or changes therein. Additionally, a stroke properties dialog box can be 
used to set the edge or line style, thickness and color of lines, and to change those 
properties. 

[0101] Graphic dialog boxes may also be used to edit other features of a graphic 
element. For example, graphic dialog boxes may be used to create new process 
graphics which include adding a graphic element property to a graphic element and 
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binding a graphic elemrait property to a runtime environment. Such a binding dialog 
box may provide a browser that enables a user to browse through different tags or 
variables defined within the control system or other runtime environment to locate 
desired tags, variables, names, etc. to perform binding. Likewise, other dialog boxes 
may be used to add visuaUzations, to add visual triggers, to browse through graphic 
elements or displays, and to add events. 

[01 02] Thus, as will be undearstood, tiie graphical editor 50 provides sTq)port for 
defining graphic element intrinsic proposes, support for gr^hic element 
visuaUzations including creating and manipulating graphic primitives or shapes, 

adding dynamic behaviors, specifically transformation animations (rotation, 
translation, scale, and skew) and property animations (length animation, color 
animation, etc.) and defining conditions that trigger the execution of dynamic 
behaviors. Still fiirther the graphical editor 50 provides support for storing and 
retrieving graphic elements in the database, including support for graphic element 
serialization into an xml blob, and support for categorizing graphic elements in a 
graphic elements Ubrary. Furthermore, the system provides for storing graphic 
element in a user-defined categories or sets, locking or providing security for such 
graphic elements, storing the graphic elements in user defined or other useful 

categories, versioning gn^hical elements, etc. 

[0103] In any event, once created, a graphic element is stored in a graphic elem^t 
database in a manner that is unbound to process variables or other data within the 
runtime environment ofthe process plant. This stored graphic element is not 
necessarily used in any displays, but is available for such use as this element is now 
capable of being downloaded to a runtime environment and of being bound to 
particular actual or simulated physical elements within the process plant or the 
process control system. When bound, the intrinsic properties ofthe ^aphic element, 
such as the process variable, the set point, the current speed, etc. are tied to and bound 
to data references within the runtime environment. 

[01 04] Fig. 1 3 illustrates a manner in wliich graphic elements can be tied or bound 
to actual physical components or elements within a process plant or a process control 
system used in a process plant. In particular, each graphic element 192 includes an 
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XAML 194, which essentially defines the visualizations for element, and associated 
scripts 196, animations 198, triggers 200, actions 202 and events 204. The graphic 
element 192 also includes a reference table 206 which Usts or includes all the 
references associated with the XAML 194 that are available or open and exposed in 
the XAML 194. The reference table 206 is essentially made up of or includes the 
properties and parameters of the graphic element, as well as any other variables or 
references used by the scripts 196, animations 198, triggers 200, actions 202, and 
events 204. The variables or entities within the reference table 206 may refer to or be 
boimd to variables, tables, table entries in other programs, or to any other types or 
kinds of data defbued elsewhere in the process control S3^tem. 

[0105] As illustrated in Fig. 13, a resolution table 208 is used to tie the references 
or variables within the reference table 206 to the actual process control environment 
or other mntime enviroimient. Generally speaking, the resolution table 208, which 
may define references either directly or via aliasing, is provided or created for the 
gr^hic element 192 when the graphic element 192 is actually configured to be used 
in a particular display within a runtime environment and is downloaded to a runtime 
machine. Before or during operation of the gr^hic element 192 within a display, the 
resolution table 208 resolves the aliases and other parameters and ties these resolved 
data connections to the reference table 206 to provide a binding between the variables 
within the reference table 206 and the actual data sources within the process control 
system or other runtime environment. 

[0106] To prevent unnecessary usage of processing power within the process 
control system during runtime, graphic elements and the graphic displays in which 
they are used need not remain bound to the runtime environment when not actually 
being displayed or used on any display screen. Instead, the resolution table 208 may 
be bound to the reference table 206 of the graphic element 192 only when the graphic 
element 192 is ruiming or being displayed on a screen within the runtime 
environment. 

[0107] Because each graphic element is tied to the process control system or 
runtime environment through the use of a reference table 206 and a resolution table 
208, and because binding occurs after the graphic element is created at a system level 
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and copied and loaded into a runtime environment or machine, the graphic element 
192 may be boimd separately to different data sources for different uses at different 
times. Still further, the graphic element 192 can be bound to data that is generated by 
or available through any number of different sources, including data sources within 
the different functional areas 42 of Fig. 2, such as data sources associated with contix)l 
activities, maintenance activities, modeling activities, simulation activities, 
configuration activities, etc. 

[01081 For example, as illustirated in Fig. 14, a display element 192 can be tied to, 
and can be used to display or process data generated in or made available from vastly 
different types of data sources. These data sources can include control environment 
data sources 210, like contiioller programs such as the well-known DeltaV control 
system, OPC data sources 212 which provide connections to other systems via the 
well known OPC connection interface, maintenance data sources 214 like the well 
known AMS system, higher level or business systems 216, like the well known 
Ovation system, and even data sources that use competitive systems 218, Uke 
competitive control applications. In this maimer, the graphic element 192 may be 
used to display data or and visualizations of physical elements at any level of the 
system usmg data fix>m any application within the system, even if tiie data comes 
from or originates in vastly different types of applications, including ^plications 
associated with competitive sj^ems that were never intended to operate together. 
Thus, because the graphic elements and the graphic displays created from graphic 
elements are created at a system level, they can be used to provide yisuaUzations of 
what is happening within the plant for any purpose, even if different types of software 
are accessing and running different hardware and software components within the 
plant. 

10109] Because of the modular nature of the graphic elements, it is possible to 
automatically or semi-automatically create graphic elements from device descriptions 
PDs) written in the well known and well supported device description language 
(DDL). In particular, device manufacturers typically provide a DD for each device 
they make which defines, in the DDL, the parameters associated with the device, how 
to communicate with the device, limits for the device, etc. As a result, a graphic 
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element creation application can read the DD for a device in the DDL to determine 
the type of device and the important parameters, limits, etc. associated with that 
device and can then define these parameters as the intrinsic properties or parameters 
of the graphic element for the device. The program may also select or define a basic 
shape-composite as a visualization for the device, and may select one or more generic, 
scripts to use for providing basic actions and animations for the device, either based 
on inforaiation firom the DD or based on templates stored for devices of the device 
type defined by the DD for the device. If desired, during this process, the program 
may query a user to provide information on the device or to make selections as to 
what animations, visualizations, primitives, etc. to use for the graphic element. 

[0110] For a more complete or well-defined graphic element, the program may 
store various generic graphical templates for different types of devices, such as for 
sensors, valves, motors, tanks, etc. The program may then determine the template 
graphic element to use based on the device type as defined by the DD for the device. 
If desired, the template may provide for or have various choices or options available 
to be used in the graphic element and these choices may be determined based on 
information within the DD for the device or based on user input. Thus, for example, 
the template may provide for various intrinsic parameters associated with various sub- 
types of devices, such as sensors, and the program may determine the intrinsic 
parameters to define for the graphic elem^t based on the information within the DD. 

[0111] Various elementary scripts may be provided as part of the template and may 
be used to provide behaviors for the visualization. Again, the scripts to be used in the 
graphic element may be chosen automatically bsised on the information within the 
DD, such as the device type, etc. or, if desired, based on questions to the user. 
Additionally, the various limits or variables used in the script may be determined firom 
information within the DD. Thus, for example, a script, such as one that provides a 
rotating graphic, may be chosen to be used or provided within the graphic element if 
the DD indicates that the device is a piece of rotating equipment, and certain aspects 
of the rotational graphic, such as the speed, when the graphic changes color, etc. may 
be based on limits associated with the device as defined within the DD. These limits 
may be, for example, normal or rated operating speed, the defined overspeed or 
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underspeed conditions or limits, etc. As another example, if the device is a sensor, the 
high and low values of the sensor may be used to provide graphics associated with the 
current reading of the sensor, graphics depicting whether the sensor is broken, etc. 
[01121 In this manner, a basic graphic element may be created automatically from a 
DD for a device when the device is attached to or recognized within a process plant 
by defining certain basic scripts, graphic animations, visualizations and intrinsic 
parameters for the graphic element based on the type of device and known 
characteristics of device as defined within the DD for the device. This automatic 
creation of a grapMc element provides a user with some ability to integrate a newly 
added device into graphics, automatically, and without having to perform much, if 
any graphic editing for the device, so that devices may be automatically supported in 
graphic displays, at least at an elementary level, when the DD for those devices is 
loaded into the system. In other words, a user may automatically create a gr^hic 
element from a DD for a device by providing a DD for a device to the system and 
then running the program to create a graphic element for the device from the DD. 
Thereafter this graphic element may be used in one or more graphic displays to model 
or provide a visualization for the device, which provides the user with the ability to 
model the device or to iUustrate the device within gr^hic displays without having to _ 
manually create a graphic element for tiie device. 

10113] As noted above, once a number of graphic elraaents 74 of Fig. 3 have been 
created, the graphical editor 50 maybe used to create one or more graphic displays, 
such as the displays 76 of Fig. 3. hi fact, if desired, the display editor 50 may be 
provided to a user or purchaser with a number of pre-configured graphic elements, 
which may have various visuaHzations associated therewith, such as visualizations for 
different industries, different fimctional uses, etc. The graphical editor 50 will then 
allow the user to create custom elements, as well as to create or build graphic displays 
76. 

[01141 Generally speaking, to create a display 76, the user will select from a library 

of graphic elements 74 and other visual elements and place them together to build up 
a display. After a graphic display is complete, the resulting data structure or object 
may be stored in a database, such as a configuration database, as a display class object 
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having all of the various elements, intrinsic properties and visualizations defined as a 
single definitional entity. This display class object, however, will be unbound to 
process variables and not necessarily used in any runtime displays. If desired, this 
class object may be stored in the database as an XML blob, having visualizations, 
scripts, etc. all stored and concatenated together as an XML entity. Thereafter, 
individual graphic displays may be created fi:om this class object, and these individual 
graphical displays may be assigned and downloaded to operator workstations or other 
runtime environments. 

[0115] When a display is downloaded, the graphic element definitions therein will 
be converted into Avalon controls, compiled into assembUes and dq)loyed on the 
target machine, i.e., the runtime machine. The display, which itself is an Avalon 
entity, will reference the compiled control assemblies and, in addition, a custom data 
source may be generated which acts as a data adapter connecting the Avalon controls 
to the backend data sources like the control or maintenance runtime applications. In 
this manner, the graphic displays (and if desired individual graphic elements) may be 
created and edited in one language, stored in another language or form (e.g. as an 
XML blob) and run in a third language or form (e.g., as Avalon controls tied to scripts 
written in any of various executable languages). 

[0116] Referring now to Fig. 15, a screen 220 may be produced by the graphical 
editor 50 to enable a user to create one or more graphic displays. Generally speaking, 
a graphic display is composed of interconnected elements that represent physical 
devices within a plant, and may include or display additional information associated 
with those devices. Each of the graphic elements in a graphic display includes a set of 
intrinsic properties that equate to process variables, constants, or other external values 
and, as explained above, each graphic element may have several visual 
representations, which may include dynamic behavior, for example color changes or 
animation. Additionally, the graphic display may include static elements, such as 
text, boxes, etc, user dynamos which allow the user to interact with the graphic 
display in some manner, variable box«s which may display process or other 
information to the user, etc. 
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(01171 Similar to the edit screen 1 12 of Fig. 5 for a graphic element, the example 
graphic display editor screen 220 of Fig. 15 includes a main edit canvas 224 in which 
a graphic display is built and a palette section 226 where template graphic elements, 
primitives or other hbrary elements can be displayed, and from which these various 
elements can be selected and dragged and dropped onto the main edit canvas 224. 
The main edit canvas 224 provides a diagram view in which the user interacts to 
create and edit graphics, either primitives or composites, and provides vector graphics 
editing and viewing features. The editor 50 enables a usct to place graphics objects, 
such as graphic elements, anywhere in a boundless space which may be inside or 
outside the display frame currently displayed in the edit canvas 224. Thus, the main 
edit canvas 224 may depict only a portion of the display currently being created and a 
user may pan the view to display other parts of a display, zoom in and zoom out to 
change the magnification level of the view, and rotate the view to obtam the most 
convenient orientation on which to work on the display at any given time. As will be 
understood, however, all drawing and manipulation of graphic objects are completed 
in the main edit canvas 224. To aid in the drawing, the X-Y position of the view can 
be read from rulers 227, the magnification level may be displayed in a dropdown list 
on a toolbar 228 and may be changed by selecting entries on a zoom popup, etc. 
[01 181 The screen 220 also includes a hierarchy section 230 which depicts a 
hierarchical display or listing of the elements within the main edit canvas 224, a 
properties section 232 which lists the properties or parameters associated with the 
display being created in the canvas 224 or with highUghted elements within the 
canvas 224, and a binding section 234 which illustrates or lists the manner in which 
different parameters or features are bound to elements within the process control 
system or any other runtime environment. Additionally, the screen 220 includes a 
toolbar 236 listing the various views or layers associated with the graphic display 
being created in the main edit canvas 224. More specifically, any particular display 
can have various layers or views that may be used by different people in different 
contexts, such as an operator display, a maintenance display, a simulation display, a 
modeling display, an engineering display, a business display, etc. In the example 
screen 220 of Fig. 15, the toolbar 236 includes three views or levels, illustrated as an 
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Operation view (currently being shown in the main edit canvas 102) which provides a 
typical control operator's view, an Eng/Maintenance view, which provides a typical 
maintenance or engineer's view and a Training view, which provides a simulation 
view used in simulating the process plant or a portion of the process plant depicted in 
the display being created. Because there are no elements selected within the main edit 
canvas 224 of Fig. 15, the properties section 232 displays the current name of the 
display being created along with features of the display, such as the width and height, 
a description provided by the creator, a name, a background description and any other 
information that a creator may want to store for the display. Similarly, because there 
are no actual elements placed in the main edit canvas 224 of Fig. 15, the hierarchy 
section 230 only shows the name of the display, and no bindings are shown in the 
bindings section 234. 

(01191 During the creation of a display, a user may place an element such as a 
graphic element onto the main edit canvas 224 by accessing that element via, for 
example, one of a set of categories of elements defined within the pallet section 226. 
In the example of Fig. 15, the pallet section 226 illustrates different categories of 
elements that may be placed into the main edit canvas 224 and connected together to 
create a complete display, including actuator elements, calculation and control 
elements, processing elements, properties and measurements, shapes, user interface 
controls and user defined elements. Of course any other kinds and categories or sub- 
categories of predefined elements may be provided or accessed in the pallet view 226. 
In this example, actuators may include valves and other actuator elements, while 
calculation and control elements may include any control related elements, such as 
indications of controllers, control loops such as PID control loops or other types of 
control loops, function blocks, control modules, etc. Processing elements, as 
illustrated in Fig. 15, may include tanks, reactors, mixers or other elements which 
process materials in some maimer, as well as any other types of devices, units, etc. 
Properties and measurement may include boxes or display elements that are designed 
to show properties or measurements or other data within the runtime environment, 
such as process vaiiables, alarais, etc' Shapes maybe primitives or other predefined 
shapes, while UI controls may include various user interface control elements, like 
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buttons, sliders, knobs, tool boxes, etc. which the user may manipulate on a display 
screen to effect input to the display. Of course, user defined elements may include 
any predefined elements, such as any other graphic elements or higher level elements 
made fi-om graphic elements. In one case, user defined elements may include prooess 
units, process plant areas, or other higher level process entities. As noted above, 
access to user defined elements may be limited based on the identity of the user using 
the editor 50 or may be globally accessible. It will, of course, be realized that any 
other elements, shapes, etc. can be placed within the pallet section 226 under any 
appropriate headings to keep fliese elements organized and easily accessible by a user. 

[0120] When a user places an elemrait ^uch, as a mixing tank, into the main edit 
canvas 224, this element may be rendered in the canvas 224 using the default 
visualization for that element. In this case, the graphic hierarchy section 230 will 
show the element and will provide a hierarchy of sub-elements for that element, such 
visualizations, animations, primitives, etc. associated with that graphic element, in a 
manner similar to that depicted in Fig. 5. Still fiirther, when a graphic element is 
shown in the canvas 224 that includes visualizations or animations that niay be bound 
to the runtime environment, tide bmdings subscription section 234 will illustrate the 
currently defined bindings. 

[0121] If desked, the user may select or change the visualization of a gr^hic 
element in the main edit canvas 224 or in the pallet section 226 by selectuig a 
different visualization in any desired manner. The user may perform this 
visualization selection function using a dropdown list or box, which may be accessed 
by for example right-clicking with the mouse pointer over the element, or by selecting 
a different visuaUzation within the hierarchy section 230, or in any other desired 
manner. Fig. 16 illustrates a portion of the main edit canvas 224 and the pallet section 
226 of the screen 220, in which a vertical tank element 240 is shown as being placed 
within the main edit canvas 224 firom the pallet section 226. The vertical tank 
element 240 is a copy or instantiation of a template or a class vertical tank element 
241 depicted in the pallet section 226. However, additional visualizations for the 
vertical tank 240, including visualizations 1-S shown in a sidebar 242 accessed by a 
right click on the mouse when the mouse pointer is over the visualization 240, are 
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able to be selected as the visualization to be used for the vertical tank element 240 
when in the display being created in the edit canvas 224. As illustrated in the pallet 
section 226, a similar type of sidebar display 243 may be obtained by right-clicking 
on the template vertical tank element 241 in the pallet section 226 to obtain or view 
the possible visualizations of the template tank element 241. Selecting a different 
visualization in the sidebar 242 will change the visualization of the tank element 240 
as used in the canvas 224, while selecting a different visualization in the sidebar 243 
will change the default setting or visualization for fhe template tank element 241 as 
stored in the pallet section 226. 

[0122] In addition to selecting graphic elraients and other elements from the pallet 
section 226 to create a display, a user may also use or select items from the toolbar 
228 depicted in Fig. 15 to obtain basic drawing tools, such as lines, shapes like 
squares, rectangles, circles, pentagons, etc., text, etc. and may use these simple 
drawing tools or elements to draw lines or to add text within the display. 
Additionally, the user may add connector elements to the display within the canvas 
224 using the toolbar connector elements 245 shown in the toolbar 228. When 
selected, the connector element 245 may provide the user with a list of coimectors to 
use in the display using, for example, a dropdown menu, a dialog box, etc. Possible 
connector elements include pipes, conveyor belts, electrical lines, fluid flow lines or 
other types of connectors which actually connect one hardware element, such as a 
tank, a mixer, a pump, etc., to another hardware element, such as a valve, a sensor, 
etc. Such connector elements and providing connector elements between differ^t 
representations of physical devices such as valve tanks, pimips, etc. is explained in 
more detail in U.S. Publication No. 2004/0153804, which is expressly incorporated by 
reference herein. The connector elements may allow a user to interconnect different 
elements within the display being created and mate with the connector points defined 
for the different elements as explained above for graphic elements. For example, pipe 
connectors may be used to attach different elements which have pipe coimector 
points, while a duct connector may be use to attach elements which have been defined 
with duct connector points. If desired, the editor 50 may implement connection mles 
that only allow a user to connect different graphic elements, such as a valve and a 
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tank, with the proper type of connector, as defiaied by the connection points of the 
valve and the tank. Of course, the appearance of the connection elements may differ 
based on the connection type to provide a better look and feel to the display being 
created with connection elements. 

[0123] Of course, the toolbar 228 may contain other vector drawing tools and 
standard commands or functions, such as typical File optioiis (new, open, save, save 
as, close, exit, etc.). Edit options (such as undo, redo, cut, copy, paste, ddete). Find 
options, etc. Additionally, the tool bar 228 may include menu items that provide 
graphic related commands, such as an Add Property function, which may be used to 
add a graphic element intrinsic property, an Add Event function which may be used to 
add a graphical event, an Add Visualization function, which may allow a user to add a 
visualization, an Add Visual Trigger function, which may open a dialog box to allow 
the user to enter information regarding the trigger to be created, etc. Still further, a 
menu may allow for Format functions (such as setting related Text, Line and Fill 
properties for text, lines and two-dimensional and three-dimensional images) and 
Shape functions, which may include grouping or ungrouping of objects, selecting tiie 
order of objects from front to back, alignment of objects hoih vertically and 
horizontally, etc. The toolbar menu 228 may also provide functions which enable a 
user to apply animation to objects, and such animations may be applied to a primitive 
of an element or to one more elements of an object, such as by animating an element 
width, color, shape, etc. to provide skewing, rotations or scaling of the shape, to rotate 
or to flip elements, etc. Of course, a user may obtain access to the animations and 
actions associated with each element within the display and may change these 
animations and actions using appropriate dialog boxes or other programming tools. 

[0124] As will be understood, a user or designer may use the display editor 50 and 
in particular may interface with the screen 220 of Fig. 15 to quickly and easily create 
graphic displays made up of standard two-dimensional or even three-dimensional 
graphic elements that may dynamically show measurements, actuators and process 
equipment. Also, static elements and user dynamos associated with control and 
calculations are supported and may be provided in the displays. Additionally, the user 
may define layers to address the interface requirements of different users of the 
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graphic displays by, for example, creating operator, maintenance and simulation 
displays using the same elements with a slightly different view or surrounding 
information. 

[0125] Fig. 17 illustrates a display screen 300 of an example graphic display, in the 
form of a control operator display, that may be created using the graphical editor 50. 
The display screen 300 includes a reactor element 310 connected to a valve element 
312 and to one or more pump elements 314 via connector elements 316, which are in 
this case fluid flow lines. Fluid flow or stream elements 318 provide references to the 
streams of materials coming in and leaving the section of the plant depicted by the 
screen 300. As will be xmderstood, the graphics witiiin the display screen 300 may be 
created by selecting and interconaecting various graphic elements together, and thus 
the display screen 300 may include high resolution graphics, animations, actions, 
visual triggers, etc. developed in the manner described above with respect to 
individual graphic elements. Of course, additional graphics, including animations, 
actions, visual triggers, fluid flow elements, etc. may be added at the graphic display 
level. In this manner, animation and user actions may be incorporated into the 
graphic display. For example, using this capability, static graphic components for 
process equipment may be modified to indicate the status of the equipment, e.g. if a 
motor is on or is tripped, the operating condition or position of a valve, etc. 
Additionally, animation may be used to represent dynamic data associated with the 
equipment, such as showing the level of a tank being filled (e.g., using a filling 
technique) or showing the status of an agitator through display changes (animations) ^ 
that indicate motion. Likewise, data display elements 319 may be placed in the screen 
300 to show process data or other data developed outside of the display 300 but 
related to the operation of the components in the display 300. 

[0126] If desired, the graphic display 300 may also include dynamos or user 
interface buttons 320A and 320B, that enable a user to interface with the display 300 
in a maimer that allows the user to view additional information or to take actions with 
respect to the runtime environment via the interaction with the display screen 300. In 
some cases, these interactions may be implemented with visual tinggers or actions as 
described above with respect to graphic elements. For example, the button 320A may 
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provide the user with a further view of information about the cooling tower makeup, 
while tiie button 320B may provide a faceplate display for the reactor 3 10. Thus, 
while the display 300 includes a set of elements that illustrates the pieces of 
equipment that make up a process or a part of a process using tibree-dimensional 
components, which as m the past may be based on graphics imported from a number 
of different sources including, for example, M-Tools, Auto-Cad, Windows metafiles 
such as Visio, vector drawings, JPEG and bitmap image formats, the screen 300 can 
now include animations to perform, for example, rotations, sizing, scaling, skewing, 
color changing, etc. at the element level to provide more interesting and realistic 
animations, and therefore more understandable displays. 

(01271 Still further, basic user intaface components such as knobs, dials, slide bars 
and buttons may be shown in the display 300 and may be dynamically linked to 
inforaiation or controls within the control system or oflier runtime environment. Data 
view elements or dynamos may also provide or illustrate key parameters associated 
with measurements in control functions, alarms, events, etc. For example, a dynamo 
maybe used to display a further screen having information related to a control loop 
parameter, and engineering units and may be shown next to the dynamo to provide 
context to the value displayed by the dynamo. The status of process alarms associated 
with a control loop may be reflected in the dynamo through color change, for 
example, a change in the background color of the control parameter value. Also, to 
eliminate clutter in the display, the fact that a loop is not in a designed normal 
operative mode may be indicated through color change. Of course, such dynamos 
may be made to conform with any standard. 

[0128] In one example, when an operator accesses a user interactive component or 
a dynamo, a script or other program may pidl up a further screen or display, such as a 
faceplate display or control panel display, examples of which are illusteated in Fig 18. 
For example, when a user interface button, such as the button 320B shown in the 
screen 300 is accessed, a faceplate for the reactor 310 may be presented to the 
operator, and the operator may then use this faceplate to modify or view details about 
the reactor 310. In the example of Fig. 18, the faceplate infomiation 350 is associated 
with a control loop (named FIG2_28/TC2-1) for the reactor 310 which the user may 
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access via the button 320A in the screen 300. Using the portion 350A of the faceplate 
350, the user may change the mode (from cascade to, for example, manual or auto) 
using the buttons 352 (the operation of which are defined by action routines), may 
view the current values of the operating parameters on the shder displays 354, may 
change a set-point associated with control loop using an arrow 355, etc. Additionally, 
the user may be provided with infomiation on the limits and tuning parameters of the 
control loop in the display section 3 5 OB and may enable simulation capabilities in the 
section 356. If desired, the section 350B may be obtained from the view of the 
section 350A by selecting one of the buttons 358 on the section 350A. Likewise, the 
user may access still frirther information about the control loop, such as trend data, 
diagnostic data, etc. or may access and run control and diagnostic programs such as 
loop tuning programs via the other buttons 358. Thus, any otiber activities, screws, 
and actions may be accessed via the display 300 in response to user actions taken or 
allowed on the screen 300. 

[0129] Where the control system supports the use of aliases in the definition of 
similar pieces of equipment, the dynamic display components may also be designed to 
support dynamic referencing based on the piece of equipment selected in the display 
screen 300. In such cases, pre-configured aliases and attributes may be used in place 
of an object tag or graphical attributes normally defined as part of a display object. 
This aliasing capability supports a high degree of flexibility and re-usability, because 
similar display objects may connect to different I/O points and represent different 
graphical attributes, appearances, and security. Such capability may eliminate the 
need to re-build similar display objects or similar displays for different pieces of 
replicated equipment within a plant In this manner, the same graphic display may be 
used to view different hardware units that are the same in makeup and usage within a 
plant. 

[0130] Of course, the display screen 300 of Fig. 17 may be designed to support 
toolbars, including both horizontal (below the display) and vertical (to the right of the 
display) toolbars in addition to or instead of the toolbar illustrated on the top of the 
screen 300. If desired, default toolbars may be provided to support the time and date 
display, viewing of an alarm list with direct access to the alarm display required to 
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acknowledge the alaim or silence the alann, navigation to an alann summaiy display 
or menu, a main menu, or other standard menus or displays, system status displays, 
etc. 

[0131] Fig. 19 illustrates a display screen 400 associated with a more advanced 
graphic display, i.e., one have more elements, connections, user interface actions, 
dynamos, and other data references. In particular, the screen 400 illustrates the 
operation of a lime kihi unit in which air and other combustion fuel products are 
pumped or fed through pumps 412, valves 404 and associated connector elements to 
an input 406 of a kihi barrel dryer 408. Likewise, process material in a tank 409 is fed 
from a sheet conveyer device 410 which transports the lime through the barrel dryer 
408. Of course, each of these elements and the other devices illusfrated in the screen 
400 may be graphic elements which may be created individually and placed within 
the screen 400 as described above. The input 406 of the barrel dryer 408 may include 
an animated graphic element showing a fire or flame 415 as an animation when the 
dryer 408 is in operation, to clearly indicate the operation of the kiln unit to a viewer 
of the screen 400. AdditionaUy, the temperatures at various points in the dryer 408 
maybe indicated with dynamos or temperature display boxes 416 and, if desired, 
temperatures at these variom points may be indicated via the color of the fire 
animation, the dryer 408 or in any other manner. Likewise, other process parameters 
such as hood pressure, kihi speed, total air, methanol, input, primary and secondary 
air inputs, oil and gas inputs, etc. may be illustrated with parameter boxes, as shown 
in Fig. 19, with the values of the variables within the boxes being tied to and obtained 
from specific references within the process control system. Of course, other physical 
components of the lime kiln unit are illustrated in flie screen 400. 
[0132] However, various other information may be provided on the screen 400 that 
maybe obtained from other data sources within the runtime environment, such as 
other applications which process data from the control system or from the devices 
within the control system. Such applications could include, for example, control 
applications, maintenance applications, diagnostic applications, business applications, 
etc. For example, a trend graph 420 showing the temperature (in degrees) of the 
system versus time is displayed in the upper center of the display screen 400 and is 



-57- 



wo 2005/109130 



PCT/US2005/015942 



tied to a data historian or a trend application and automatically plots this data. 
Likewise, a chart 422 providing a summary of the operation of the kiln 412, which 
may be provided by a business application that tracks various business aspects, such 
as profit, energy use, production rate, etc. of the kiln, is displayed at the upper left- 
hand side of the screen 400. Still further, other information that may be useful to the 
user, such as historical trends, help information, kiln information, control constraints, 
kiln energy and other information may be accessed by selecting the user interface 
buttons 424 at the upper portion of the display screen 400. Still further, an alarm 
banner 430 or other banner may be provided at the bottom of the screen 400 and may 
be tied to an alarming application. Of course, all of these elements and features of the 
display screen 400 may be provided and programmed into the display using the 
features of the display editor 50 described above. Additionally, these and other 
features may be combined in a graphic display in any desired manner to create any 
desired type of display. Still further, any desired, animations and graphical actions 
could be provided in the screen 400 to provide more useful or understandable visual 
information to a viser, to allow the user to view other related information more directly 
from the screen 400, etc. 

[0133] Thus, as illustrated in Fig. 19, information from various different data 
sources, including process elements as accessed by the controller sub-syst^n, 
applications in the form of maintenance, control, diagnostic, tuning, and business 
applications, historical data or tend data from databases such as a data historian, or * 
any other data sources, may be displayed in the display screen 400. Still further, other 
information or displays may be accessed directly from the display screen 400 via user 
links to such displays. In this manner, the graphic display illustrated by the screen 
400 provides more information, in a manner that may be more useful, to a user. 

[0134] Because the editor 50 may be used to create any graphic displays using a 
common set of graphic elements, connection elements, etc. the display editor 50 may 
be used to easily create similar or related displays. Such displays may relate to and 
show the same set of plant hardware but illustrate different information for that 
hardware for different purposes, such as for control operator purposes, simulation 
purposes, maintenance purposes, etc. In this case, a common or base display may be 
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made showing the hardware elements associated with a plant or a section of a plant 
and different displays may be created using that base display, but providing different 
information for different users or types of user. 

[0135] As an example. Figs. 20A-20E show example displays, including an 
operator's view, an engineer's view, a manager's view, a simulation view and a 
maintenance view, created for a lime kihi unit showing the same basic hardware 
elements in the same configuration and using the same visuahzations, but having 
different information added for different functional purposes. Thus, each of the 
displays of Figs. 20A-20E has the same look and feel because they are made with the 
same display editor usmg the same basic graphic elements, and are therefore easy to 
navigate between while retainmg an understanding of the information being presented 
and how it relates to the hardware within the plant. 

[01361 In particular. Fig. 20A illustrates an operator's view 500 of a kihi unit have 
a lime and mud feed source 502 (which may be a stream element) feeding raw 
material through a pump 504 to a cold end 506 of a kihi dryer 508. A conveyor 510 
removes the processed lime from a hot end 5 12 of the kihi dryer 508 and deposits the 
lime in a tank 514. A product Une or sh«am element 516 indicates the amount of 
product (lime) exiting the tank 5 14. Likewise, fuel from a fuel soiHce stream 
indicator 520 is provided through a valve 522, the color of which may ©r^hically 
illustrate tlie operation of the valve, into the hot end 512 of the kihi dryer 508. A fen 
524 pumps air through a duct connector element 526 to the hot end 512 of the kihi 
dryer 508 where it is mixed with tiie fuel. Animations, such as fire or flame 528 may 
be shown in the hot end of the kihi dryer 50S to illustrate the operational state of the 
kihi dryer 508. Likewise, an induction fan 530 draws air from the cold end 506 of the 
kihi dryer 508 through additional ductwork 532 and sends this air to a stack, as 
indicated by a stack stream element 534. Still further, various variable or parameter 
boxes are illustrated showing the values of various process parameters, such as 
temperatures at various parts of the system, the speed of the barrel of the kihi dryer 
508, air and fuel flows, etc. As will be seen, this hardware and these variable boxes 
are common throughout the screens of Figs. 20A-20E and provide the basic elements 
of the displays that causes these displays to have the same look and feel. 
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[01371 However, each of the screens of Figs. 20A-20E includes additional 
information, user interface buttons and actions tailored to different functions within 
the plant. For example, the screen 500 of Fig. 20A is an operator's view and 
illustrates residual carbonate as measured, estimated and provided by a lab test in a 
box 540, the total energy and the specific energy of the kiln in a box 542 as well as a 
trend graph 544 showing the past and future trends of the temperatures provided by a 
model predictive coutrol routine that are key to achieving optimum operation. 
Additionally, the screen 500 provides various user interface buttons or dynamos 548 
that allow a user to view additional information about an associated item,, such as 
control loop information, further operational infomiation of an elemCTit, etc. 

[01381 The screen 550 of Fig. 20B illustrates an engineering view, which is very 
similar to that of Fig. 20 A, but which shows, via dotted lines 552 the measurement 
locations important for control and the signal paths to show how the basic control 
system and the model predictive control system work together to optimize operation. 
The screen 560 of Fig. 20C provides a management view that, while showing the 
basic operation of the kiln unit, does not provide user interface buttons that allow 
additional information to be obtained on individual components or control loops of 
the system. Still further the management view 560 includes a chart 562 showing the 
total energy, specific energy and residual carbonate (xmconverted feed) from lab 
measurements over the past day and month. This information may be provided from 
a business application run in a business computer, for example. 

[0139] Still further. Fig. 20D provides a simulation view 570 which allows a 
simulator to change parameters within a simulated system and view the simulated 
results. The view 570 may be used, for example, to train operators, to test different' 
future modes of operations, etc. As shown in Fig. 20D, the simulator may change 
parameters via one or more dialog boxes 570 provided to the simulation operator 
through one or more user interface buttons on the screen 570. The process simulation 
view 570 may be used in an off-line situation for training or in an on-line situation to 
provide added information that can be useful in detecting future problems. The 
process simulation can be generated fiom the graphics because the types of equipment 
and their connections are known as a result of using smart objects or graphic elements 
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having simulation capabilities in the construction of the operator graphics. These 
smart objects are described in detail in U.S. Publication No. 2004/0153804. 

[0140] Likewise, Fig. 20E illustrates a maintenance view 580 that provides 
information on or into the state of the equipment within the kiln unit. In the view 580, 
equipment failure may be shown using indications 582 and 584 of eqmpment health. 
In this case, the indications 582 and 584 (not all of which are labeled in Fig. 20E) are 
half circles, with a fill color showing or specifying the current monitored health of the 
equipment. In the view 580, the indications 584 indicate equipment with less than 
optimal health. Of course, these indications 582 and 584 may be provided from 
maintenance or diagnostics applications. Still further, as will be understood, when a 
process problem is detected, a maintenance technician can use the screen 580 to drill 
down and find the recommended procediires to fix the problem. As an example, a 
plugged mud filter will need to be washed, which will require shutting off the feed 
and putting the kihi in an idle mode, which can then be done from the operator's view 
500 of Fig. 20A. Operations will also know to check on the quality of the feed for 
excessive grit, which covild be caused by a process problem upstream. Thus, as 
shown by tiiis simple exairyple, various interactions between the different functions, 
such as detecting a problem and fixing it, may be done simply and easily by switching 
between different views that have the same look and feel and thus are easy to 
navigate. Of course, the information in the various screens of Figs. 20A-26E may be 
layered on the display and may be only shown based on the user of the screen, if 
desired. Also, the information shown for each element or smart object may change 
with the user or the identity of the user. 

[01411 Still fiuiher, additional displays may be provided for and associated with the 
displays of Figs. 20A-20E. These displays may include, for example, control 
configuration displays such as those of Figs. 21A and 21B. A control display 585 of 
Fig. 21 A illustrates the manner in which various control signals are sent to and from 
the various hardwai e elements of the kihi unit depicted in Figs. 20A-20E to a 
controller, as well as the tags or variable names associated with these control 
elements. A confa-ol display 590 of Fig. 21B illustrates a control module, showing the 
control routines that implement control of the kiln unit of Figs. 20A-20E. While not 
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specifically shown as such, the control display 585 of Fig. 21 A may be made using 
the same elements of the screens 20A-20E (with the same or different visualizations 
associated with these elements) or may use different elements. Likewise, because the 
displays 585 and 590 of Figs. 21 A and 21B may be made using the display editor 50, 
these displays may be provided with any of the graphic and animation capabilities 
discussed above. Still further, the control displays 585 and 590 may be accessed via, 
for example, the operators view 500 of Fig. 20 A via one of the user interface buttons 
548 provided thereon to allow an operator to easily obtain access to the current 
control set up firom the operator's view 500. 

[0142] Thus, as will be understood firom the discussion provided above, various 
related displays may be created by the editor 50 and these displays may be layered in 
a number of manners, hi particular, the displays may be layered as described above to 
provide related or similar operator, business, simulation, maintenance and engineering 
views and these views may be easily accessible fi-om one another. Still fiirther, 
different displays may be layered or connected together in a manner that reflects a 
particular hierarchical, logical or physical stmcture of the plant. Thus, for example, 
displays may be made for different physical or geographical areas of a plant. Thus, a 
single display may be created showing the major areas of the plant, and addition 
displays may be created showing the basic stmcture, for example on a unit by unit 
basis, within each area of the plant, while still further displays may be created for 
each unit. Li manner, a user may drill down through the displays to obtain greater and 
greater detail associated with smaller and smaller sections of the plant. As another 
example, displays for different sections or portions of the plant may be concatenated 
or attached together via user interface buttons so that the operator can easily scroll 
through the different displays in a forward and reverse direction to view the different 
but physically connected sections of the plant or components of the plant in a logical 
manner. 

[0143] These types of display layering are illustrated in more detail by the diagram 
of Fig. 22. Ih particular, a general or overall plant overview display 600 may provide 
a display that illustrates the basic or high level structure of the entire plant, although it 
may not provide much detail about any particular section or part of the plant. From 
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the display 600, a user may be able to select <using interface buttons) or drill down to 
any particular section or area of the plant to puU up one or more displays 602 of area 
A or one or more displays 604 of area B of the plant. As indicated in Fig. 22, area A 
may have n separate displays associated therewith, all of which are logically 
connected in series with one another to reflect process flow through that area of the 
plant or some other logical structure associated with area A of the plant. The n 
displays of area A, labeled 602a, 602b, . . . 602n may be accessed using a page 
forward or page back type of action in which the user can scroll from one display to 
the next. In this manner, a user can easily scroll through the displays form one section 
of area A to another section of area A in a manner that makes sense to the operator. 
Still further, as illustrated in Fig. 21, the operator may obtain predefined infomiation 
or other display information from separate ones of the displays 602a-602n. Thus, the 
operator may be able, when viewing the display 602a of area A, to obtain a further 
display 610 depicting a predefined trend of key paramet^s in the display 602a. 
Likewise, when viewing the display 602b, the operator may be able to access a list or 
document 612 having start-up and shut-down procedure information. Of course, the 
user could scroll between the displays 602a, 602b, etc. in a forward and a reverse 
direction. 

[0144] Likewise, when viewing area B, which is illustrated as including m displays 
604a- 604m, the user may scroll between displays at the same level of detail using 
forward and reverse (next and back) buttons witiiin the displays so that it is possible 
for an operator or other user to access displays that contain information upstream or 
downstream of the displayed section of ttie process. In addition, dynamos or other 
user interface buttons may be provided to allow another display to be accessed, to 
obtain other information associated with elements within the current display. 
Through the use of these tools, it is possible to create a display hierarchy from which 
an overview display may be used to access the key display in -each process area. 

[0145] Additionally, as illustrated in Figs. 20A-20E, displays may be layered so 
that numerous displays exist for the same section or part of a plant, but which are used 
for different functional purposes, such as for operator actions, maintenance actions, 
simulation actions, business actions, engineering actions, etc. These separate 
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ftmctional displays are illustrated in Fig. 22 as being layered beneath the displays 
602a, 602b, etc. and may be accessed from one another, if so desired. Thus, when an 
operator or user is viewing the display 602a, the user may switch between or access 
the other functional displays for that section of the plant, such as the maintenance 
view, the simulation view, the business view, etc., if such access is permitted. Of 
course, the layering of the maintenance view, the operator view, the simulation view, 
etc. in this manner using the same basic display elements provides for easy switching 
between these views and a bettCT understanding of what is happening within tiie plant 
with respect to the different functions within tiie plant. 

[0146] To implement this an other fimctionaUty, graphic displays may be created to 
include an indication of the intended role (or function) for the graphic display. Such 
roles may include, for example, a faceplate display, a detail display, a primary control 
display, a schematic display, a maintenance display, a business display, a simulation 
display or any other user defined role. The role is part of the graphic display and may 
be used, when the graphic display is assigned to a control module or to a hardware 
device to define the use and access to that display dunng runtime. The indication of 
the role assigned to the graphic display may be used to indicate where and to what 
sections of the configuration system or plant a particular display may be assigned. 
Additionally, this role information may be used to determine which displays a 
particular user may access, based on the job being performed by the user. For 
example, control operators may not be able to view or access graphic displays defined 
as simulation or business displays. 

[0147] The graphic display capabilities described above may also be used to create 
special displays to allow the status of critical equipment to be easily monitored. Some 
examples of these types of displays include first out indication on a process shutdown, 
vibration monitoring, bumer management, sootblower operatipn, and safety system 
status. Of course, the associated displays can be stmctured to summarize the 
information and, in cases where moving equipment involves animation, for example a 
sootblower, animation may be effectively used to allow an operator to quickly access 
or imderstand the operation of the system. Additionally, the calculation capability of 
most control systems may be used to implement on-line calculation of operation cost. 
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efficiency, etc. and this type of information may be easily incorporated into the 
operator's graphic display so that the operator can use this information to improve the 
process operation. Also, a variety of techniques may be used to integrate subsystem 
infomiation in the control system so that standard graphics and dynamos maybe used 
to create operator displays to allow access to subsystem information firom a higher 
level display. In some cases 3D plotting of matrix values may be perforaied to show 
information (e.g. sheet gauging information). 

[0148] Additionally, it will be noted that the graphic elements and displays may be 
advantageously implemented using vector graphics, such as tiiose provided by 
Microsoft Avalon controls, to provide flexibility and speed. The use of vector 
graphics provides the ability to use scalable graphics to enable the display being 
created to be scaled and sized to fit a particular display machine as well as to provide 
animations that use scaling. 

[0149] Generally speaking, and as described in greater detail in the co-pending 
q>plication entitled the creation of each process graphic display, and graphic display 
element contained therein, is recorded in a respective textual description set forth in a 
first declarative format. Script commands in each description provide an efficient, 
non-memory intensive mechanism for defining the displays, despite the complexity of 
the graphics to be rendered. The declarative format and, therefore, the script 
commands, may be based on any one of a number of different markup languages. 
More particularly, a markup language basted on XML may be relied upon to set forth a 
rendering definition (also called an XML blob) for each display and display element, 
and this XML blob may be used to store these displays and elements in a 
configuration library or database prior to being downloaded into a process runtime 
environment. To support advanced graphics, such as animation, the markup language 
may also define such graphics in accordance with a vector graphics scheme. 

[0150] As indicated above, and as described more particularly in the co-pending 
application entitled **Markup Language-Based, Dynamic Process Graphics in a 

Process Plant User Interface" which has been incorporated by reference, the dynamic 
nature of the process graphics is designed to reflect current values of process plant 
parameters as on-line or simulation conditions change. To this end, the process 
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graphics may be linked to sources for the data reflecting such changes. Each XML- 
based description may accordingly include one or more data source references that 
generally identify a data source location for each respective dynamic graphic 
parameter (e.g., a tank interior's changing color) to be modified in accordance with 
the data. The data source location may also be left open for later specification during 
configuration via the editors, such that the script identifies an alias or placeholder to 
refer to the data source or path information to be specified later. Because the data 
source information and other characteristics of the process graphic displays (e.g., 
behaviors such as event handling) are specified via the XML-based description, the 
XML-based language may be referred to as PGXML, or process graphics XML. 

[0151] Upon finishing the configuration and design work toward defining a process 
graphic display and its constituent elements, the configuration engineer or other user 
may elect to process the PGXML description in preparation for dovmloading the 
process graphics to the operator workstations or other user display devices. Generally 
speaking, each PGXML description of the graphic displays and. display elements is 
processed to generate (i) script in a vector graphics format compatible with a graphics 
rendering engine to be used, and (ii) code having instmctions specifying the data 
source references and any other non-graphics functionality (e.g., behaviors) of the 
display. The vector graphics format of the script may also be a declarative, or XML- 
based language. In embodiments utilizing a Microsoft Avalon user interface 
architecture, the vector graphics script may be set forth in Microsoft XAML. Other 
embodiments may utilized the open source format, SVG (Scalable Vector Graphics). 
The code may be set forth in C# or any other suitable programming language. 

[0152] In some embodiments, the vector graphics script and associated code are 
then combined and compiled into files that set forth executable commands for the 
operator workstation or other user display device. To this end, a respective dynamic- 
link library (DLL) file may be created for each process graphic display and graphic 
display element. In any event, such compilation of the vector graphics script and 
associated code may be performed prior to downloading to minimize network data 
transmission requirements. 
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[0153] Once created, graphic elements and graphic displays may be stored in a 
configuration database as generic or template objects and may be stored as class- 
based or non-class based objects or elements prior to being used in a runtime 
environment. Generally speaking, the graphic elements and graphic displays 
discussed herein may be modules, in the form of display modules, as described in 
U.S. Publication No. 2004/0199925, which is incorporated by reference herein. A 
class module (object) is one that is not boxmd or tied to any particular hardware or 
device in a process plant or a process control system, but is an object from which 
other objects which are bound to the process plant or Hie process control system may 
be instantiated. Generally speaking, to configure a process plant and, in particular, a 
runtime environment of a process plant, a configuration engine such as one of the 
configuration applications 33 shown in the configuration workstation 20 of Fig. 1, 
niay be used to associate the graphic objects {including graphic elements and graphic 
displays) with other logical and physical entities within the process plant, including ' 
logical entities like control modules, equipment modules (e.g., xmit modules), process 
modules, etc. or physical entities such as operator workstations or other display 
devices. In some cases, the graphic objects may be class objects and may be 
associated with other class objects, like equipment module class objects or control 
module class objects, or may the graphic objects may be individual objects and may 
be associated with instantiated objects, such as objects that have been boimd to 
eguipment within the process plant and downloaded, for example, to a controller, a 
workstation or other piece of equipment within the process plant. 

[0154] Thus, the above-identified graphic elements and graphic displays may be 
configured within a process plant configuration system and downloaded to hardware 
within a process plant runtime environment in a manner similar to tiie manner in 
which other class objects are stored within a library and are configured within and 
then downloaded to various sections or subsections of the process control system, as 
described in U.S. Publication No 2004/0199925. In particular, the configuration 
engine, which operates on data within a configuration database such as the database 
28 of Fig. 1, uses a configuration database liierarchy, such as that illustrated in Figs. 
23 and 24, to enable a user to view and alter the configuration of the process plant. 
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The configuration hierarchy screen 700 of Fig. 23 shows that the configuration 
database for the control system 702 (labeled as the DeltaV control system), includes a 
Library section 704, a System Configuration section 706 and a Search Results section 
708. 

[0155] The Library section 704 includes class objects and other object definitions 
which have not been assigned or downloaded to tiie runtime environment, but are 
instead stored as templates or generic and imbound objects. As indicated in Fig. 23, 
the Library section 704 includes a Control Modules section 710, a Devices section *. 
712, a Process Modules section 714 and an Operator Interface section 716 as well as a 
Batch section and a Safety Instrument Systems section (not indicated with a number). 

[0156] While the Control Module section 710 is not expanded, this section of the 
configuration database gaierally includes the different control modules, such as 
control module templates and control module class objects, which have been created 
for the process plant to be used in various controllers and other control devices within 
the process plant. Still further, the devices section 712 includes indications of device 
objects which ixiight include indications of actual devices and types of devices used 
within the process plant, such as valves, sensors, controllers, workstations, etc. as well 
as indications of device class objects, equipment class objects, etc. which define 
logical elements associated with different devices or hardware within the process 
plant. Still fiirther, the process module section 714 includes the various process 
modules created for the process plant, including process module templates and 
process block definitions defined for these process modules. Such process modules ' 
are described in detail in U.S. Publication No. 2004/0199925 and so will not be 
described fiirther herein. 

[0157] However, as indicated in Fig. 23, the Operator Interface section 716 of the 
configuration hierarchy 700 stores information associated with the graphic objects 
described above. In particular, a graphics section 720 includes various composite 
process graphic definitions, graphic class objects and graphic templates, which define 
the various graphic elements and graphic displays that have been created for the 
system. It will be noted that the composite process graphic definitions section 
generally includes the graphic elements created for the system, the process graphic 
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classes section includes the graphic displays created in the manner described above as 
class objects, while the process graphic templates may include non-classed based 
graphic displays and other template objects. The graphic objects stored in this section 
of the configuration database are generally unbound objects that may be used to create 
other objects, and that may be used during a configuration process to define the 
manner in which graphic elements and graphic displays are to be bound to the various 
hardware and software within the process plant. Still further, a Layout section 722 
under the Operator hiterface section 716 defines various layouts for the operator 
interfaces, while a Roles section 724 defines various roles which may be implemented 
on operator interfaces, as well as roles fulfilled by various ones of the graphic 
displays and elements. 

[0158] Thus, the configuration database as illusfrated by the configuration 
hierarchy 700 may include a section that stores graphic objects including graphic 
elements and graphic displays as generic templates, as class objects or as specific or 
individual elements or displays which, while not being bound to specific process 
entities, may be used to define elements or displays which will be boxmd to specific 
process entities. Generally speaking, a configuration engineer or other user may use 
the hierarchy 700 to configure a process plant to include graphic display capabilities 
ia a manner discussed in more detail below. 

[0159] Fig. 24 illustrates a hierarchy screen 730 in which the System Configuration 
section 706 has been expanded to illustrate how process graphic elements and graphic 
displays may be associated with various logical and physical entities of the process 
plant as part of a system configuration. In particular, a Process Graphics section 734 
under the System Configuration section 706 defmes various graphic displays that • 
have been generally defined to be downloaded to the process plant for use in a 
runtime environment. Generally speaking, the ^aphic displays and elements within 
the Process Graphics section 734, which may include for example, faceplate displays, 
operator displays, detail displays, maintenance displays, simulation displays, etc., will 
be downloaded to each display unit (e.g., each workstation or other display device) 
within the process plant, as the Process Graphics section 734 applies to the entire 
system configuration. However, graphic elements and displays may instead be 



-69- 



wo 2005/109130 



PCT/US2005/015942 



associated with particular sections of the system configuration including a Control 
Strategies section 736 and a Physical Network section 740, which may limit the 
display devices on which these graphic elements and displays will be available. 

[0160] Generally speaking, the Control Strategies section 736 defines the various 
control routines assigned to or strategies implemented with respect to different 
physical and logical sections of the process plant. Various ones of the graphic 
displays (which again may be any types of displays such as faceplate displays, control 
displays, maintenances displays, etc.) may be assigned to specific subdivisions or 
subcategories of the Control Strategies section 736 including, for example, to areas 
(such as to the areas named Area A 742 and Area_B 744), to control modules 
associated with aresis, such as to a Control Module section 746 and to process 
modules assigned to areas, such as to a process module 748. Thus, as illustrated in 
Fig. 24, a display section 750 is associated with the Area_A section 742, which 
defines all the displays which are used for and in Area_A of the plant. While not 
broken out, the displays under the folder 750 could include various displays 
associated with different sets of hardware in Area_A such as the different displays 
602a-602n of Fig. 22, as well as various sub-displays accessible firom these displays, 
such as displays 610 and 612 of Fig. 22. The roles defined for the displays may 
indicate the manner in which tiiese displays are accessible &om one another or to an 
operator using a display device. Thus, as described with respect to Fig. 22, a user 
may scroll through the displays in the section 750 to view different parts of the 
Area_A of the plant or to view more detail with respect to any particular area, 
including more detailed displays of particular portions of a hi^er level display not 
shown in as much detail in the higher level display. 

[0161] Still further, displays can be assigned to specific control modules within the 
Area_A section 742 as indicated by the Displays icon 752 under the Control Module 
section 746. In this case, the displays 752 are associated with a control module loop 
(named LOOP) and may specifically be control operator displays associated with that 
particular control loop. Again a role defined for a display may indicate its role within 
an operator station as part of a control display. Still further, as illustrated with respect 
to the Area^B section 744, displays 754 may be generally associated with the area 
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while displays 756 may be associated with particular process modules assigned to an 
area. In this case, a Display icon 756 is associated with a process module named 
PMOD2, which is a process module associated with the equipment in Area_B. The 
PMOD2 may be, for example, a unit module or an equipment module or any other 
type of process module. 

[01 62] Thus, as generally indicated under the Control Strategy sections 736, 
displays may be associated with particular control strategies or control definitions, as 
those control definitions are created within the configuration system. As shown in the 
example of Fig. 24, displays may be associated with control definitions defined on an 
area-by-area basis, such as for the area sections 742 and 744, as well as on a control 
module-by-control module basis, such as for control modules 750 and on a process 
module-by-process module basis as indicated by the display section 756. 
Additionally, if desired, equipment items maybe associated with roles, which allows 
the displays associated with those roles to be accessed dynamically firom equipment 
elements. Such equipments roles and displays may be stored in the process graphics 
section 734. 

[0163] Additionally, displays may be also assigned or associated with actual 
hardware elements within the process plant, including operator workstations or other 
display devices. Thus, as indicated under the Physical Network section 740, specific 
displays may be assigned to specific operator workstations or other runtime machines 
having displays. In the particular example of Fig. 24, the Physical Network section 
740 includes a Control Network 760 which has associated hardware, such as a 
controller named CTLRl , a ProPlus station, which may be a configuration station, 
and an operator workstation named OperatorStation 762. The OperatorStation 762, 
which defines or is associated with a particular workstation or user interface within 
the plant, include alarms and events fimctions, operator activities, a continuous 
historian function and simulation activities associated therewith, although other 
activities or functions such as maintenance activities, business activities, etc. could be 
associated with and performed on any particular user interface. In this manner, 
particular user interfaces may be assigned to roles within the process plant and have 
the displays for those roles stored in or downloaded to the display device. 
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[0164] As indicated in Fig. 24, displays 764 and 766 are assigned to the operator 
function or activities as well as to the simulation function or activities performed by 
the workstation 762. While not shown in Fig. 24, displays may be assigned to other 
display devices, e.g., those associated with other nodes within the process plant, to be 
implemented on these display devices. Still further, the assigmnent of displays to 
specific functions within the operator workstations or other runtime display machines 
may determine the roles or functions that these displays may perform within the 
runtime environment, such as an operator function a simulation function, a 
maintenance function, etc. Of course, tiiese various functions may be performed on 
the same display, device or on different display devices, in a manner set by the 
configuration system. Also, while the configuration. hierarchy 730 illustrates displays 
being assigned to an operator workstation, displays can be assigned to other types of 
display devices, including handheld computer display devices, like PDAs, telephone 
devices, business workstations or any other desired types of display devices. 

[0165] The configuration engine enables a user, such as a configuration engineer, 
to use the configuration hierarchy to define and manage tihie manner in which the 
process graphic displays are boimd to and downloaded withiu the process plant. 
Generally speaking, a user such as a configuration eiigineer, can create, delete, 
rename, assign and download display objects within the configuration system in the 
same maimer that the user can do so with respect to other objects. More particularly, 
the configuration engine enables graphic displays to be integrated into the 
configuration of the process plant by defining where (to what devices) to assign these 
displays for execution and the process entities (logical and physical) to which these 
displays should be bound during runtime. If desired, a configuration hierarchy screen, 
such as those of Figs. 23 and 24, may be used to indicate downloads that are needed 
and to implement version control on the displays. 

[0166] Configuration can occur at multiple levels within the configuration system. 
In the first place, a configuration engineer may first associate a display class object ' 
with a module class object in the Library section 704, which binds a particular display 
class object to a particular module class object, such as an equipment module class^ 
object, an area module class object, etc. Thereafter, when the module class object is 
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instantiated and assigned (or other configured) to a particular part of the process plant, 
the display objects (e.g., graphic displays) associated with the instantiated module 
object are bound to the same hardware along with the module object, and thus no 
additional effort need be performed to assign a graphic display to the appropriate 
hardware within the plant or to download this ^aphic display object to the 
appropriate hardware. Instead, in this case, the graphic display object follows the 
configuration of the module object to which it is boimd. Still further, when a display 
class object is associated with a module class object, as described above, changes 
made to the module class object may automatically cause these changes to propagate 
to those same elements within the associated display class objects, and these changes 
may then be propagated down to actual instantiated versions of graphic displays. In 
one example, if a graphic display includes a mixer (equipment class object) which 
contains a . control module called Loop, arid this control module is selected and 
renamed, the configuration system may automatically change the references to the 
Loop within the graphic display to the new name, to ttiereby assure that the grjq)hic 
display bindings are updated with the new.name. However, the actual newly changed 
displays may still need to be downloaded to the runtime machine for the changes to 
take place in the runtime system. If desired, indications that a download is required 
may be placed next to the displays as stored within the configuration hierarchy, such 
as by placing a blue triangle next to the appropriate ones of the graphic displays icon. 

[01 671 On tlie other hand, graphic displays may be assigned separately or directly 
to different components within the process plant or configuration system. In 
particular, as illustrated in Fig. 24, individual graphic displays may be placed in the 
Process Graphics section 734 under the System Configuration section 734. These 
displays may be placed in this section by, for example, being selected in the Library 
section 702 and being dragged and dropped onto the section 734. Of course, other 
manners of moving graphic displays to p^icular sections of the hierarchy 730 may 
be used as well. In any event, the graphic displays in the section 734 might include, 
for example, faceplate displays or other class based or non-class based displays and 
are generally eligible to be downloaded to all workstations within the plant or the 
section of the plant covered by the System Configuration section 706. 
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[0168] However, a user can move displays out of the Process Graphics section 734 
and into specific subsections in order to control the identity of the workstations (or 
other display devices) within the process control system that will have access to these 
displays and, therefore, to control the identity of the devices on which these displays 
can be used. To assign a specific display to a logical or physical plant section, the 
user may, for example, select a graphic display, drag and drop the graphic display 
onto the specific section of the configuration hierarchy 730 to thereby define the 
association between that graphic display and the logical or physical entities to which 
tiiat display is to be associated. The resolution table for a display may be 
automatically filled out at the time that this configuration step occurs, based on the 
section of the configuration into which a display is dropped or associated. 

[0169] For example, graphic displays may be dragged fi-om the Library section 702 
to the Process Graphics section 706 to associate the display with the runtime 
environment. Also, graphic displays in, for example, the Process Graphics section 
734 may be moved into other sections, such as into the Area A Displays section 750 
(making this display specific to the Area_A entity aiid fimctionaUty but generally 
available oh any Area__A display device), the AreaJB Displays section 754, etc. 
Likewise, graphic displays may be associated with sub-sections of logical entities, 
such as being associated with the control module named LOOP (as indicated by the 
displays folder 752), which makes these displays specific to this logical entity and 
available only on machines that perform or that are defined as being associated with 
this control loop fimction. Additionally, displays may be assigned to specific display 
devices or fiinctional subsections of display devices, such as that defined by the 
operator function within the OperatorStation 762 or the simulation fiinction 770 
within the OperatorStation 762. While not specifically shown in detail, the user can 
also assign graphic displays to an area, a cell, a unit, an equipment module, as well as 
to different control sections to. define the manner in which the graphic displays are 
associated with and to be used within the process plant. 

[0170] When a graphic display is assigned to a logical entity, such as to a control 
strategy, like that defined by an area designation, like Area__A or Area_B, the graphic 
display is assigned to the physical interfaces (e.g., workstations) to which these 
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logical entities are assigned. Similarly, when a display is assigned to a unit, a cell or 
an equipment module, the display is assigned to the workstation or other intetface 
devices to which that unit, cell or equipment is assigned. 

[01711 When a module includes multiple graphic displays, the module may define 
the roles for those displays or define roles that each display fulfills, as defined by a 
role indications assigned to the graphic displays when the displays were created. 
Access to those graphic displays within any display device may tiienbe associated 
with or limited by the role defined for the display. Still fiirther, if a graphic display is 
assigned to an area or to a module, a reference to this graphic display may show up as 
a graphic display in the Displays folder of the area or module to which it belongs. 
Once a graphic display is assigned to an area or module, the display references owned 
by this area or module, and hence this display, will follow the area or module during 
any assignment or movement of the area or module. On the other hand, when an area 
or module is assigned to a workstation, the display that belongs to that area or module 
will be automatically assigned to the operator subsystem or fimction of that 
workstation as defined by the role of the display. Of course, individual graphic 
displays may be assigned directly to the operator subsystem of a display device by 
being placed directly within or under the particular interface device or subsystem of 
the interface device within the Physical Network section 740 of the configuration 
hierarchy. 

[01 72] Thus, as will be understood, graphic displays may be assigned to individual 
nodes, to control areas, to control modules, to process modules or to other logical 
control entities, as well as to individual display devices and subsystems thereof by 
being dragged to and dropped in each of these entities within the configuration screen 
730. Of course, if desired, the same graphic display may be assigned to multiple 
stations arid the status of each display (downloaded or just assigned) may be indicated 
by an icon provided for each display name in the various folders within the hierarchy 
730. If desired, other icons can be used in the hierarchy 730 to indicate when graphic 
displays are locked in memory or whether they can be maintained in virtual memory 
on the disk. 
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[0173] Generally speaking, graphic displays are made up of a display content (e.g., 
an XAML script that defines the manner in which the display will appear visually on 
a display screen), local tables and references which may be references to other 
displays as well as references to runtime parameters such as control parameters, etc., 
references to display controls, runtime aliases (some of which may bind at runtime); 
local table references and global table referCTices. Generally speaking, the 
configuration engine treats the graphic part of the graphic element (the XAML) 
separately from the references, making it easier to deal with and use graphic displays. 
In particular, the configuration system may bind a graphic display during the 
configuration process by filling out the references which do not use dynamic aliases 
based on the assignments performed in the configuration hierarchy. Thus, for 
example, when a user drags a graphic display &om the Process Graphics section 734 
or from the Library section 704 of the configuration hierarchy 730 to a particular area 
or control module, binding is automatically performed in the graphic to bind the 
references within the graphic display to the specific, elements associated with that area 
or module. In this manner, download bindings may be performed automatically based 
on the configuration being performed by the user, which reduces the amount of work 
the user must perform manually to specify these bindings. 

[0174] Still fiirther, if there are unresolved bindings at the configuration step, the 
configuration engine may query the user to provide information to resolve the 
bindings, such as to change the bindings or the references. Still fiirther, if desired, 
bulk edit tools, such as a spreadsheet program like Microsoft Excel® may be used to 
assist a configuration engineer in filling out or defining resolutions or binding 
parameters during the configuration process. In any event, these configuration steps 
fill in the resolution table 208 discussed with respect to Fig. 13 which enables the 
graphic displays to be used in a runtime environment. Thus, the user can perform 
bindings and downloading of graphic displays (and graphic elements) in generally the 
same manner that the user does so with respect to the process modules described in 
U.S. Publication No. 2004/0199925. 

[0175] Of course, the user or configuration engineer may unassign graphic 
displays by chcking on the graphic display and removing it from the hierarchy 730 or 
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Otherwise engaging a dialog box to cause this graphic display to be xmassigned. Still 
fiirther, a user may view the manner in which a particular graphic display or set of 
graphic displays is assigned, and such infoimation maybe provided by, for example, a 
dialog box 800 shown in Fig. 25. The dialog box 800 of Fig. 25 indicates the manner 
in which each of two displays. Display 1 and Display2 is configured within the process 
plant. In particular, the dialog box 800 indicates where each of the displays are used 
(e.g., Displayl is used in a plant area called Area_A and in the control module called 
Modi), the physical station to which it is assigned (e.g., Displayl is assigned to an 
operator station called Operl) and the role that the display fulfills (e.g., Displayl is a 
primary display in each of its uses). 

[0176] It will be understood that the display roles can also be changed in any 
desired manner, and that the roles may be used to indicate a portion of the 
configuration system to which the graphic display can be assigned or who can use the 
gr^hic display, i.e., for what function. Graphic displays may be used to fulfill 
multiple roles if so desired. Of course, as noted above, when a user assigns an area, 
or a module of some kind to a workstation or other display device, any displays 
associated with that area or module are also assigned to the workstation to assure that 
the graphical support for that area or otheir module is provided on the woricstation. 
Also, whai a graphic display is assigned to a workstation or other display device, the 
graphic display may be assigned to a subsystem of the woricstation based on fbs role 
of that graphic display, such as whether the graphic display is a simulation display, an 
operator display, etc. Additionally, the user may drag and drop gr^hic displays onto 
particular subsystems of a workstation or other display device, and if the role is 
incorrectly assigned, the configuration system may present a dialog box to indicate to 
the user that an incorrect assignment is being made or to allow the user to change the 
roles of the graphic display. 

[01771 After perfomiing appropriate or desired assignments using the configuration 
engine and the configuration hierarchy 730 of Figs. 23 and 24, the user operator may 
perform an actoal download of the graphic displays, which causes the graphic 
displays to be actually downloaded to the appropriate operator workstations as 
defined in the configuration hierarchy 730 for the purposes and roles defined in the 
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configuration system. During this downloading, the bindings within the displays are 
resolved based on the assignments to the areas, loops, control modules, process 
modules, etc., as well as to the operator workstations or other display devices. 

[0178] If desired, the Search Results section 708 of the configuration hierarchy 
(shown in Fig. 23) may enable a user to perform searches for any individual graphic 
displays or graphic elraients used in graphic displays throughout the process plant or 
configuration system. In particular, the configuration engine may include a search 
engine which, when engaged by the user, may perform searches for specific graphic 
displays or graphic elements, and may store the results of such searches in the Search 
Results section 708 to provide the user with a complete listing of the uses of any 
particular graphic element or graphic display. Such searches are useful to enable 
users, who are making changes, to view which graphic displays need to be changed or 
what downloads might need to occur in order to implement those changes. 

[0179] When implemented, any of the software described herein may be stored in 
any computer readable memory such as on a magnetic disk, a laser disk, or other 
storage medium, in a RAM or ROM of a computer or processor, etc. Likewise, this 
software may be delivered to a user, a process plant or an operator workstation using 
kny known or desired delivery method including, for example, on a computer readable 
disk or other transportable computer storage mechanism or ovei: a communication 
chaimel such as a telephone line, the Intemet, the World Wide ^Veb, any othCT local 
area network or wide area network, etc. (which delivery is viewed as being the same 
as or interchangeable with providing such software via a transportable storage 
medium). Furthermore, this software may be provided directly without modulation or 
encryption or may be modulated and/or encrypted using any suitable modulation 
carrier wave and/or encryption technique before being transmitted over a 
communication channel. 

[01 801 While the present invention has been described with reference to specific 
examples; which are intended to be illustrative only and not to be limiting of the 

invention, it will be apparent to those of ordinary skill in the art that changes, 
additions or deletions may be made to the disclosed embodiments without departing 
from the spiiit and scope of the invention. 
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